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

  Hi Stefan,

  That looks great. I would only suggest s/unwanted/unauthorized/
to highlight that it's not just some proprietary cruft a manufacturer
would add that could be understood by his decoders, it's something that
was not placed there by the participants in the protocol.

  regards,

  Dan.

On Wed, June 10, 2009 8:51 am, Stefan Döhla wrote:
> 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: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.
>>>
>>>
>>
>>
>>
>
>
> --
> Dipl.-Ing. Stefan Döhla     | Email: stefan.doehla@iis.fraunhofer.de
> Multimedia Transport        | Phone: +49 (0)9131 776 6042 (!NEW!)
> Audio Department            | Fax:   +49 (0)9131 776 6099 (!NEW!)
> Fraunhofer IIS              |
> Am Wolfmantel 33            |
> 91058 Erlangen, Germany     | Web:   http://www.iis.fraunhofer.de/amm
>
>