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

  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:dharkins@lounge.org]
>> Sent: 2009 Jun 09 1:29 AM
>> To: avt-chairs@ietf.org; 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" <dharkins@lounge.org>
>> Date:    Mon, June 8, 2009 4:22 pm
>> To:      iesg@ietf.org
>>          secdir@ietf.org
>>          avt-chars@tools.ietf.org
>>          fluffy@cisco.com
>> Cc:      frans.de.bont@phillips.com
>>          "malte.schmidt@dolby.com"
>> <ralph.sperschneider@iis.fraunhofer.de>
>>          stefan.doehla@iis.fraunhofer.de
>> -----------------------------------------------------------------------
>> ---
>>
>>
>>   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
>> secdir@ietf.org
>> 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.
>