Last Call Review of draft-thornburgh-adobe-rtmfp-07
review-thornburgh-adobe-rtmfp-07-secdir-lc-orman-2013-06-27-00

Security review of 
Adobe's Secure Real-Time Media Flow Protocol
draft-thornburgh-adobe-rtmfp-07

Do not be alarmed.  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 is an informational RFC describing an existing Adobe protocol.
It has the feature of allowing sessions to change their IP addresses
and to use forwarders to help in NAT traversal.

The draft does not specify the cryptographics requirements and
processing in enough detail to facilitate interoperable
implementations, and I don't recommend advancing it.

The draft generically specifies the cryptographic features that would
provide privacy and authentication.  All specifics are left to the
implementor.  The cryptographic profiles could be trivial (rot13 and
casting out nines, for example).

How is the cryptographic profile specified?  Is there only one, to be
used by all implementations RTMFP?  If not, how do two implementations
agree on which profile they will use?

How is the "default session key" selected?  The text mentions the
possibility of multiple default keys.  In "Security Considerations":
   ... to allow for different applications of RTMFP using different
   Default Session Keys to (intentionally or not) share network
   transport addresses without interference.
I don't see how this could work.

What is the algorithm for encrypting with the default session key?
Note that the crypto profile is supposed to determine the keys, but
there is not necessarily an interface that accepts a default key
and produces usable encryption and integrity/authentication keys.

Is there any response for "endpoint discriminator unacceptable"?

I did not see any "MUST" requirements for rejecting data that fails to
pass cryptographic checks.

How are message integrity and authentication achieved?  Is it required?
Section 2.2.3 says:
   "The packet encryption layer is responsible for data integrity and
   authenticity, for example by means of a checksum or cryptographic
   message authentication code."
That does not seem to require that the message integrity be tied to
the Endpoint Discriminator.

Is there anti-replay prevention?  I cannot tell.  There are sequence
numbers, but they could be spoofed under some definitions of the
cryptographic profile.

Section 2.2.2:
   "The 32-bit Scrambled Session ID is the 32-bit Session ID modified by
   performing a bitwise exclusive-or with the bitwise exclusive-or of
   the first two 32-bit words of the encrypted packet."
This is security-by-obscurity and is not worth the trouble.

The Security Considerations admit that the Default Session Key is such
a weak measure that all messages that use it should be considered to
be sent in the clear.  It isn't worth the trouble of using it.

There are robust IETF security protocols that could be layered over RTMFP.

I recommend removing all references to cryptography from this
document.  

Hilarie