Subject: Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-atrac-family-18

From: actech <[email-masked]>
Date: Thu, 13 Nov 2008 18:42:25 +0900

Discus:

Alan,

Thank you for comments and advise.

>   It may be useful to define a security profile whereby all data is
> encrypted. Simple traffic analyis on the headers may be sufficient to
> negate much of the benefits of encrypting only the data portion.

Regarding on security consideration, necessary and sufficient guideline
for ATRAC streaming are fully described in published RFC(3550, 3551).
So we think it is better to simply put the reference to above RFCs,
instead of describing complex information of security profile,
confidentiality and authentication.

All of your comments and advise other than above issue are acceptable
for us, and we are now make the modification on our draft according to
your comments.

We will submit revised version in soon, if there are no problem.

Regards,

>   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 defines a packet format to encapsulate ATRAC-formatted
> audio data in RTP frames.
> 
>   Overall, the document is clear and unambiguous.  The only security
> review comments I have are for text in the "Security Considerations"
> section.  The discussion appears to worry more about audio quality than
> packet decoding errors, or malicious insertion of incorrect audio.
> 
> 
>         Certain security precautions may be desired to protect
>         copyrighted material.
> 
>   I suggest deleting this sentence.  The Security considerations is not
> intended to discuss dissemination controls on data.
> 
>    ... Encryption of the payload header,
>    however, is not as neccessary, and in fact may not be preferable if
>    the information could be useful to some third party application.
> 
>   It may be useful to define a security profile whereby all data is
> encrypted. Simple traffic analyis on the headers may be sufficient to
> negate much of the benefits of encrypting only the data portion.
> 
>    ... As multi-
>    channel transmissions are contained in single encoded audio frames,
>    there is no concern for encryption will affect interleaving data.
> 
>   I am not sure what this means.  "concern for encryption.." ?
> 
>    ... Transmitted data may be tampered or altered due to malicious
>    attempts, such as man-in-the-middle attacks.  Such attacks may result
>    in depacketization and/or decoding errors that could decimate audio
>    quality.
> 
>   Concerns about audio quality are misplaced in a "Security
> Considerations" section.  MITM attacks may lead to *incorrect* audio
> that never the less sounds "correct".
> 
>    As this payload format does not include its own means for sender
>    authentication and integrity protection, an external mechanism MUST
>    be used.
> 
>   Are there security profiles that can be defined?
> 
>    However, the chosen mechanism SHOULD protect more than just
>    the audio data bits. For example, to protect against
>    a man-in-the-middle attack, the payload header and RTP header SHOULD
>    be protected.
> 
>   This text likely belongs in the first paragraph of Section 9 (see above)
> 
>    ... Verification of the received encoded audio packets SHOULD be
>    performed so as to ensure a minimal level of audio quality.
> 
>   This text does not belong in a security considerations section.  Audio
> quality is irrelevant if protocol errors have causes buffer overflows
> that allow an attacker to control either end of the connection.  Correct
> decoding of the packets is MORE important than audio quality.  I suggest
> moving this text to the body of the document, and creating requirements
> that received packets MUST be verified, and improperly formatted packets
> MUST be discarded.
> 
>    ... As a
>    most primitive implementation, if the receiver calculates a packet
>    size differing from the payload length based on data in the payload
>    header fields, the receiver SHOULD discard the packet.
> 
>   This suggestion may be too restrictive.  If the UDP packet length is
> longer than the RTP packet length, the packet can be accepted, but the
> extra bytes MUST be ignored.  Also, improperly encoded packets MUST be
> discarded.
> 
>   Alan DeKok.
> 
> 
> 
> 

_______________________________________________
secdir mailing list
[email-masked]
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
secdir mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/secdir