Re: [secdir] [Fwd: SECDIR review of draft-ietf-avt-rtp-mps-02.txt]

[Stefan Döhla <[e-mail]>]

Hi Dan,

thanks for pointing us into the right direction. Normally, SRTP is 
recommended in RTP payload formats so that this "hitch-hiking" is not 
possible for the RTP-streamed phase in the end-to-end model.

Would an additional sentence in the spirit of this

   The AAC audio codec includes an extension mechanism to transmit extra
   data within a stream that is gracefully skipped by decoders that do
   not support this extra data.  This covert channel may be used to
   transmit unwanted data in an otherwise valid stream and it is hence
   recommended to use SRTP [RFC3711] for stream encryption,
   authentication, and integrity check.

help? The overall end-to-end integrity check is probably out-of-scope 
for IETF matters, since we probably cannot stop an encoder to add 
proprietary data to the stream that is e.g. only understood by decoders 
that conform to a specific application standard etc.

Something like the proposed sentence above is btw. already part of the 
document - but it just refers to the weak RTP encryption.

Cheers
- Stefan

Dan Harkins wrote:
>   Hi Frans,
>
>    RFC 3640 only considers one security issue associated with gracefully
> disregarding unknown content. It's correct to mention that this capability
> can be used to compromise or crash a receiver but there's another security
> consideration that I think deserve mention. Something along the lines of:
>
>       An attacker can exploit the requirement that a decoder skip over
>       unknown extensions to create a covert channel and transmit
>       unauthorized data.
>
> So even if you properly address the issue of potentially crashing there
> is still another security issue to consider. Given the nature of
> audio/video equipment it might be remote but to this naive reader it
> deserved mention.
>
>   It's like a hitch-hiker. One must take into account that a hitch-hiker
> might kill you but even if you properly address that threat you still
> have consider the fact that you might need to explain to law enforcement
> that those drugs/firearms/etc in the dufflebag in your car aren't really
> yours.
>
>   regards,
>
>   Dan.
>
> On Wed, June 10, 2009 12:51 am, Bont, Frans de wrote:
>   
>> Hi Dan,
>>
>> Thanks for your review, we will update the draft accordingly.
>>
>> With respect to your 'covert channel' comment we want to make
>> the following remark.
>>
>> RFC 3640 says:
>>     
>>> However, it is possible to inject non-compliant MPEG streams (Audio,
>>>    Video, and Systems) so that the receiver/decoder's buffers are
>>>    overloaded, which might compromise the functionality of the receiver
>>>   or even crash it.
>>>       
>> This is a general remark that hold for all audio/video formats, this
>> is not different for the format described in this draft.
>>
>> The mentioned 'covert channel', in ISO/IEC 14496-3 (MPEG-4 Audio)
>> implemented by means of the extension_payload(), is defined as a
>> backward compatible mechanism for transport of extension data inside AAC
>> payloads. Streams using this mechanism are fully compliant MPEG-4 Audio
>> streams and code points, the extension identifiers in ISO/IEC 14496-3,
>> that are not supported by a decoder are gracefully skipped.
>>
>> Best regards,
>> Frans
>>
>>
>>     
>>> -----Original Message-----
>>> From: Dan Harkins [mailto:[e-mail]]
>>> Sent: 2009 Jun 09 1:29 AM
>>> To: [e-mail]; Bont, Frans de
>>> Subject: [Fwd: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt]
>>>
>>>
>>>   Hi,
>>>
>>>   I fat-fingered your addresses in the following-- chars and phillips.
>>> Sorry about that.
>>>
>>>   Dan.
>>>
>>> ---------------------------- Original Message -------------------------
>>> ---
>>> Subject: [secdir] SECDIR review of draft-ietf-avt-rtp-mps-02.txt
>>> From:    "Dan Harkins" <[e-mail]>
>>> Date:    Mon, June 8, 2009 4:22 pm
>>> To:      [e-mail]
>>>          [e-mail]
>>>          [e-mail]
>>>          [e-mail]
>>> Cc:      [e-mail]
>>>          "[e-mail]"
>>> <[e-mail]>
>>>          [e-mail]
>>> -----------------------------------------------------------------------
>>> ---
>>>
>>>
>>>   Hi,
>>>
>>>   I have reviewed this document as part of the Security Directorate's
>>> ongoing effort to review all IETF documents being processed by the
>>> IESG. These comments were written primarily for the benefit of the
>>> Security Area directors. Document editors and WG chairs should
>>> treat these comments just like any other last call comments.
>>>
>>>   This document extends the RTP payload format to transport MPEG
>>> Surround multi-channel audio.
>>>
>>>   By extending the RTP payload format, this document states that it
>>> is "subject to the security considerations of the RTP specification"
>>> itself. It also informatively cuts-and-pastes from the security
>>> considerations of RFC 3640. I see no problem with that.
>>>
>>>   While it's not an issue that needs addressing in this draft, it
>>> seems to me that this draft takes advantage of a covert channel
>>> in an ISO Standard on the coding of audo-visual objects-- "skip
>>> unknown extension data" in a stream. RFC 3640 discusses the
>>> possibility of crashing a system using this bug^H^H^Hfeature but
>>> does not mention the covert channel possibilities. It would be nice
>>> to mention that in a successor to RFC 3640 if there ever is one.
>>>
>>> Minor issues:
>>>
>>>   - missing reference to SDP, RFC 2327
>>>   - please spell out "Advanced Audio Coding" before using the
>>>     acronym AAC (assuming that's what it meant).
>>>   - the term "High Efficiency AAC" is used after the acronym HE-AAC.
>>>     Please reverse that.
>>>
>>>   regards,
>>>
>>>   Dan.
>>>
>>>
>>>
>>> _______________________________________________
>>> secdir mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/secdir
>>>
>>>       
>> The information contained in this message may be confidential and legally
>> protected under applicable law. The message is intended solely for the
>> addressee(s). If you are not the intended recipient, you are hereby
>> notified that any use, forwarding, dissemination, or reproduction of this
>> message is strictly prohibited and may be unlawful. If you are not the
>> intended recipient, please contact the sender by return e-mail and destroy
>> all copies of the original message.
>>
>>     
>
>
>   


-- 
Dipl.-Ing. Stefan Döhla     | Email: [e-mail]
Multimedia Transport        | Phone: [phone] (!NEW!)
Audio Department            | Fax:   [phone] (!NEW!)
Fraunhofer IIS              |
Am Wolfmantel 33            |
91058 Erlangen, Germany     | Web:   http://www.iis.fraunhofer.de/amm