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

From: Alan DeKok <[email-masked]>
Date: Tue, 23 Sep 2008 15:57:24 +0200

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.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt