Request for reviewing audio, vidoe, text/rtp-enc-aescm128

This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128 These have been requested by 3GPP SA4 to be registered in the standards tree by the IESG following the SDO rules in RFC 4288. The type registration is present in Technical Specification 26.234 in section K.1.4.1: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-670.zip It is reproduced below for your information. The full media format is specified in Annex K of above specification. The registration template has been present in the document for a while and follows the template in RFC 2048. If that is a problem it can be fixed, however it will take some months. I therefore would also like to receive any further comments in that case. MIME media type name: audio, video, text 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 fulfills 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 --- 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: The security considerations clearly indicate the problems with AES Counter Mode. There are alternatives that provide efficient integrity protection. Why would we want to permit this fragile encryption mode when robut alternatives are available? At a minimum, the registration should tell us. Russ At 04:43 AM 5/16/2006, Magnus Westerlund wrote:
This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128
These have been requested by 3GPP SA4 to be registered in the standards tree by the IESG following the SDO rules in RFC 4288. The type registration is present in Technical Specification 26.234 in section K.1.4.1: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-670.zip
It is reproduced below for your information. The full media format is specified in Annex K of above specification. The registration template has been present in the document for a while and follows the template in RFC 2048. If that is a problem it can be fixed, however it will take some months. I therefore would also like to receive any further comments in that case.
MIME media type name: audio, video, text
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 fulfills 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
---
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

At 17:43 06/05/16, Magnus Westerlund wrote:
This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128
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 <">.
The URI spec is now RFC 3986. This should be fixed, also in the original spec. Also, it should probably be extended to IRIs (RFC 3987). Regards, Martin.

I'm confused if this really is a payload time - this seems at a semantic level the same as SRTP. I am concerned with how one would signal this a payload type in SDP and at the same time signal the type of payload it was encrypting for any dynamic type. I have serious reservations about this registration. On May 16, 2006, at 1:43 AM, Magnus Westerlund wrote:
This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128
These have been requested by 3GPP SA4 to be registered in the standards tree by the IESG following the SDO rules in RFC 4288. The type registration is present in Technical Specification 26.234 in section K.1.4.1: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-670.zip
It is reproduced below for your information. The full media format is specified in Annex K of above specification. The registration template has been present in the document for a while and follows the template in RFC 2048. If that is a problem it can be fixed, however it will take some months. I therefore would also like to receive any further comments in that case.
MIME media type name: audio, video, text
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 fulfills 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
---
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 Cullen, Please review the 3GPP specification. That contain examples and the whole solution specification. But in short. The indication of the protected payload format is indicated using the OPT variable of this type. Thus if you have two real payload types carrying media you need two of these, one for each of the unprotected payloads. That way you can recover them. The main difference between this and SRTP is the following. It allows for pre-encryption at the content issuer, rather than being encrypted at the content provider (media server). Thus the back-end handling of the media is protected. Please remember that this is an DRM solution. In fact the 3GPP spec says that SRTP is used for integrity protection of the content. Cheers Magnus Cullen Jennings wrote:
I'm confused if this really is a payload time - this seems at a semantic level the same as SRTP. I am concerned with how one would signal this a payload type in SDP and at the same time signal the type of payload it was encrypting for any dynamic type.
I have serious reservations about this registration.
On May 16, 2006, at 1:43 AM, Magnus Westerlund wrote:
This is a request to review the media types: audio/rtp-enc-aescm128 video/rtp-enc-aescm128 text/rtp-enc-aescm128
These have been requested by 3GPP SA4 to be registered in the standards tree by the IESG following the SDO rules in RFC 4288. The type registration is present in Technical Specification 26.234 in section K.1.4.1: http://www.3gpp.org/ftp/Specs/archive/26_series/26.234/26234-670.zip
It is reproduced below for your information. The full media format is specified in Annex K of above specification. The registration template has been present in the document for a while and follows the template in RFC 2048. If that is a problem it can be fixed, however it will take some months. I therefore would also like to receive any further comments in that case.
MIME media type name: audio, video, text
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 fulfills 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
---
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
participants (4)
-
Cullen Jennings
-
Magnus Westerlund
-
Martin Duerst
-
Russ Housley