Subject: [secdir] Security review of draft-thornburgh-adobe-rtmfp-07

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 21 Jun 2013 11:05:26 -0600

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

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 24 Jun 2013 11:32:17 -0700

hi Hilarie.  thanks for your review.  comments/replies inline.

> From: Hilarie Orman [mailto:[email-masked]]
> Sent: Friday, June 21, 2013 10:05 AM
> 
> Security review of

this draft describes a generic framework of cryptographic operational semantics with requirements and recommendations.  the generic framework is a common part of RTMFP and belongs in this specification.  specific cryptography choices are left to applications/profiles of RTMFP.  the intention is that application-level interoperation would be achieved using this specification and a specification of the application-specific Cryptography Profile; for example, a specification describing the Cryptography Profile to be used for Flash platform communication.

> casting out nines, for example).

correct. for testing/development of the RTMFP implementation used in Adobe's products, i created a "Null Crypto Adapter" implementing (NOT RECOMMENDED) straight-copy for the "Packet Encryption" function, and a trivial session-specific key to salt a simple checksum for "data integrity".  this profile/adapter met the semantic requirements of a Cryptography Profile but was not suitable for any circumstance where actual aspects of security were desired.  however, it made debugging using a packet sniffer a lot easier!

> agree on which profile they will use?

a Cryptography Profile would be specified in another document.  the intention is that there could be different Cryptography Profiles for different applications or uses of RTMFP.  there is one defined for Flash platform communication, which has features uniquely tailored to the Flash ecosystem; however, specifics of this are unfortunately not currently publicly disclosed.  i agree that it would be valuable to have this profile available as a concrete example; however, i don't have permission to publish it at this time.  i considered designing a new cryptography profile to use as an example, but it would have no real-world implementation or deployment experience behind it and would not have the benefit of the years of refinement and experience we have with the Flash profile.  publishing such an example would probably encourage people to implement it, even though it could have serious flaws.  i concluded that creating a new example profile was a bad idea.

> I don't see how this could work.

the Default Session Key is chosen by the designer of the Cryptography Profile.  for example, in the Flash Crypto Profile, the Default Session Key is the 16 bytes of the UTF-8 coded string "Adobe Systems 02" (note: this has been widely known for years and is not a secret).  these 16 bytes form the raw key for AES-128-CBC, which is the default (and currently only) cipher used in the Flash Crypto Profile.

as far as two RTMFPs using the same network transport address, think of the different Default Session Keys as different spread-spectrum spreading codes.  if used with something like AES-128-CBC, then even a "data integrity" check comprising an interior checksum would be enough to reject as corrupt a packet using the wrong Default Session Key.

> and produces usable encryption and integrity/authentication keys.

the Cryptography Profile also determines the method of encryption (Section 2.2.3 first sentence).  in the case of Flash communication, this method is AES-128-CBC, and would be fully specified in the "RTMFP for Flash" document, were it published.

> Is there any response for "endpoint discriminator unacceptable"?

section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discriminator selects the identity of the responder.  see sections 3.5.1.4 and 3.5.1.5 for possible behavior for when an Endpoint Discriminator does not select the identity of the responder.

there are no chunks or other messages to encode "i received an EPD i didn't like for one reason or another".  what to do in this circumstance is intentionally not specified and is left to the implementer's discretion.  in the Adobe implementation, an IHello or FIHello with an EPD that doesn't select the receiver (including because it's malformed) is silently dropped (except in forwarders/redirectors).

> pass cryptographic checks.

i will add a statement to that effect in Section 2.2.3 3rd paragraph.

> the Endpoint Discriminator.

by "message integrity" i assume you mean "data integrity" in the context of packets.  data integrity is not tied to the EPD.  the EPD is a field interior to the packet, which must be tested for integrity before being parsed.  in the sentence you quoted above, i will add "of packets" after "integrity and authenticity" and before the comma.

in general, (packet) data integrity and authenticity is left to the designer of the cryptography profile. in the case of Flash communication, this is achieved using either an (interior) checksum or an (exterior) HMAC, the choice being determined during the IIKeying/RIKeying phase of the startup handshake in the respective Keying Components, and in the case of HMAC, the HMAC key being derived in a manner similar to how the packet encryption key is derived. 

> numbers, but they could be spoofed under some definitions of the

anti-replay prevention is part of "data integrity and authenticity".  in the case of Flash communication, a "Session Sequence Number" can be enabled (during the IIKeying/RIKeying phases, similar to how HMAC/simple checksum is selected) to prevent packet replay.  i will add a RECOMMENDED about anti-replay in SS2.2.3PP3.

flow sequence numbers prevent anti-replay (and enable retransmission) within a current flow; however, an observer could capture a packet that starts a new flow (using traffic analysis to figure out what packet that was), and later, after using traffic analysis to infer that flow is concluded, could replay that packet to potentially start a new flow with the same flow ID (or interfere with a new flow with the same ID).  i will add something to the Security Considerations about that, to further make the case for implementing packet-level anti-replay.

> This is security-by-obscurity and is not worth the trouble.

disagree with the characterization of "security-by-obscurity" and that it's not worth the trouble.  the intention is to make every byte of UDP payload appear to a casual observer (and especially to a meddling middlebox) to be random noise.  RTMFP is intended to be used with a strong cipher (like AES), where every ciphertext byte appears pseudorandom.  during startup, the Session ID is 0, and during the rest of the session it is a fixed non-zero value.  without the scrambling operation, there would be a tasty and consistent 4-bytes that a middlebox might want to interpret as an IP address or something, or otherwise meddle with.  if we XORed with only the first 4 bytes, then during startup (with SID 0) the first 4 bytes would be the same as the second 4 bytes.  XORing with two 32-bit words (where those 64 bits are strongly pseudorandom in the case of AES) ensures that the first 4 bytes at least don't match the next 8.

note that it's not security-by-obscurity because it's documented.  :)  note also that even if it's not worth the trouble, it *is* how this deployed protocol actually works.

> be sent in the clear.  It isn't worth the trouble of using it.

disagree. the Security Considerations section states that the Default Session Key is intended to scramble startup packets to avoid meddling by middleboxes, to obscure the content from casual observation, and to act as a spread-spectrum or subchannel code for different RTMFP applications that might be sharing a transport channel.  this is particularly important because startup packets can contain IP addresses and port numbers.  i disagree with the characterization as "admit [...] such a weak measure" -- the Security Considerations states the intent and disclaims (with a "MUST NOT") any security aspect to it.

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

true.  RTMFP could also be adapted to be encapsulated in DTLS.

> I recommend removing all references to cryptography from this

disagree. the generic (and intentionally open-ended) cryptographic framework is an essential semantic aspect of the protocol.  the normative semantics described in this document are common to any application of RTMFP.

> Hilarie

thank you very much.

-michael thornburgh

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 25 Jun 2013 08:11:13 -0400

Leaving alone everything else - there was no better encryption mode for streaming data (I assume Flash would be streaming?) than CBC? And what's the purpose of encrypting something with a key shared with the entire Universe? 

I think you're expecting too much from "error discovery" of CBC mode. Also, for the last two decades cryptographers insist that the correct way of MACing is applying outer MAC. Also, especially considering the capabilities of the later Intel chips, using HMAC after (or before:) encryption is a waste of time - there are fast Authenticated Encryption modes (GCM and OCB, to name a couple).

So far I tend to agree with Hillary, and suggest using DTLS.

Yours in confusion...

Sent from my iPad

On Jun 24, 2013, at 14:32, Michael Thornburgh <[email-masked]> wrote:

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 25 Jun 2013 10:28:29 -0700

> From: Uri Blumenthal [mailto:[email-masked]]
> Sent: Tuesday, June 25, 2013 5:11 AM
> 
> Leaving alone everything else - there was no better encryption mode for streaming data (I assume Flash
> would be streaming?) than CBC? And what's the purpose of encrypting something with a key shared with
> the entire Universe?

as mentioned in this thread, Section 2.2.3, descriptions of the startup chunks, and the Security Considerations of the memo, the Default Session Key is used at session startup, during which per-session encryption keys are negotiated.  also as mentioned in this thread and the Security Considerations, the startup handshake is encrypted with the Default Session key to scramble startup packets to avoid meddling by middleboxes, to obscure the content from casual observation, and to act as a spread-spectrum or subchannel code for different RTMFP applications that might be sharing a transport channel.

> I think you're expecting too much from "error discovery" of CBC mode. Also, for the last two decades
> cryptographers insist that the correct way of MACing is applying outer MAC. Also, especially
> considering the capabilities of the later Intel chips, using HMAC after (or before:) encryption is a
> waste of time - there are fast Authenticated Encryption modes (GCM and OCB, to name a couple).

in the Flash profile, the MAC is an outer MAC.  when HMAC mode is not selected, there is a simple inner checksum.  the inner checksum is at least as good as a checksum over a normal unencrypted packet.  as far as detecting whether a packet was encrypted with an incorrect key in checksum mode: even if the checksum succeeded, the likelihood that the incorrectly decrypted packet could parse correctly even to a first complete and valid chunk is very low.
 
> So far I tend to agree with Hillary, and suggest using DTLS.

HTH.  i invite you to read the entire memo.  note that this memo documents an existing and widely deployed vendor-supplied protocol.  note also that this memo doesn't describe the cryptography profile used by Flash (including AES-CBC, HMAC, and anti-replay measures).

-michael thornburgh

> > this draft describes a generic framework of cryptographic operational semantics with requirements
> and recommendations.  the generic framework is a common part of RTMFP and belongs in this
> specification.  specific cryptography choices are left to applications/profiles of RTMFP.  the
> intention is that application-level interoperation would be achieved using this specification and a
> specification of the application-specific Cryptography Profile; for example, a specification
> describing the Cryptography Profile to be used for Flash platform communication.
> >
> > correct. for testing/development of the RTMFP implementation used in Adobe's products, i created a
> "Null Crypto Adapter" implementing (NOT RECOMMENDED) straight-copy for the "Packet Encryption"
> function, and a trivial session-specific key to salt a simple checksum for "data integrity".  this
> profile/adapter met the semantic requirements of a Cryptography Profile but was not suitable for any
> circumstance where actual aspects of security were desired.  however, it made debugging using a packet
> sniffer a lot easier!
> >
> > a Cryptography Profile would be specified in another document.  the intention is that there could be
> different Cryptography Profiles for different applications or uses of RTMFP.  there is one defined for
> Flash platform communication, which has features uniquely tailored to the Flash ecosystem; however,
> specifics of this are unfortunately not currently publicly disclosed.  i agree that it would be
> valuable to have this profile available as a concrete example; however, i don't have permission to
> publish it at this time.  i considered designing a new cryptography profile to use as an example, but
> it would have no real-world implementation or deployment experience behind it and would not have the
> benefit of the years of refinement and experience we have with the Flash profile.  publishing such an
> example would probably encourage people to implement it, even though it could have serious flaws.  i
> concluded that creating a new example profile was a bad idea.
> >
> > the Default Session Key is chosen by the designer of the Cryptography Profile.  for example, in the
> Flash Crypto Profile, the Default Session Key is the 16 bytes of the UTF-8 coded string "Adobe Systems
> 02" (note: this has been widely known for years and is not a secret).  these 16 bytes form the raw key
> for AES-128-CBC, which is the default (and currently only) cipher used in the Flash Crypto Profile.
> >
> > as far as two RTMFPs using the same network transport address, think of the different Default
> Session Keys as different spread-spectrum spreading codes.  if used with something like AES-128-CBC,
> then even a "data integrity" check comprising an interior checksum would be enough to reject as
> corrupt a packet using the wrong Default Session Key.
> >
> > the Cryptography Profile also determines the method of encryption (Section 2.2.3 first sentence).
> in the case of Flash communication, this method is AES-128-CBC, and would be fully specified in the
> "RTMFP for Flash" document, were it published.
> >
> > section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discriminator selects the
> identity of the responder.  see sections 3.5.1.4 and 3.5.1.5 for possible behavior for when an
> Endpoint Discriminator does not select the identity of the responder.
> >
> > there are no chunks or other messages to encode "i received an EPD i didn't like for one reason or
> another".  what to do in this circumstance is intentionally not specified and is left to the
> implementer's discretion.  in the Adobe implementation, an IHello or FIHello with an EPD that doesn't
> select the receiver (including because it's malformed) is silently dropped (except in
> forwarders/redirectors).
> >
> > by "message integrity" i assume you mean "data integrity" in the context of packets.  data integrity
> is not tied to the EPD.  the EPD is a field interior to the packet, which must be tested for integrity
> before being parsed.  in the sentence you quoted above, i will add "of packets" after "integrity and
> authenticity" and before the comma.
> >
> > in general, (packet) data integrity and authenticity is left to the designer of the cryptography
> profile. in the case of Flash communication, this is achieved using either an (interior) checksum or
> an (exterior) HMAC, the choice being determined during the IIKeying/RIKeying phase of the startup
> handshake in the respective Keying Components, and in the case of HMAC, the HMAC key being derived in
> a manner similar to how the packet encryption key is derived.
> >
> > anti-replay prevention is part of "data integrity and authenticity".  in the case of Flash
> communication, a "Session Sequence Number" can be enabled (during the IIKeying/RIKeying phases,
> similar to how HMAC/simple checksum is selected) to prevent packet replay.  i will add a RECOMMENDED
> about anti-replay in SS2.2.3PP3.
> >
> > flow sequence numbers prevent anti-replay (and enable retransmission) within a current flow;
> however, an observer could capture a packet that starts a new flow (using traffic analysis to figure
> out what packet that was), and later, after using traffic analysis to infer that flow is concluded,
> could replay that packet to potentially start a new flow with the same flow ID (or interfere with a
> new flow with the same ID).  i will add something to the Security Considerations about that, to
> further make the case for implementing packet-level anti-replay.
> >
> >> Section 2.2.2:
> > disagree with the characterization of "security-by-obscurity" and that it's not worth the trouble.
> the intention is to make every byte of UDP payload appear to a casual observer (and especially to a
> meddling middlebox) to be random noise.  RTMFP is intended to be used with a strong cipher (like AES),
> where every ciphertext byte appears pseudorandom.  during startup, the Session ID is 0, and during the
> rest of the session it is a fixed non-zero value.  without the scrambling operation, there would be a
> tasty and consistent 4-bytes that a middlebox might want to interpret as an IP address or something,
> or otherwise meddle with.  if we XORed with only the first 4 bytes, then during startup (with SID 0)
> the first 4 bytes would be the same as the second 4 bytes.  XORing with two 32-bit words (where those
> 64 bits are strongly pseudorandom in the case of AES) ensures that the first 4 bytes at least don't
> match the next 8.
> >
> > note that it's not security-by-obscurity because it's documented.  :)  note also that even if it's
> not worth the trouble, it *is* how this deployed protocol actually works.
> >
> > disagree. the Security Considerations section states that the Default Session Key is intended to
> scramble startup packets to avoid meddling by middleboxes, to obscure the content from casual
> observation, and to act as a spread-spectrum or subchannel code for different RTMFP applications that
> might be sharing a transport channel.  this is particularly important because startup packets can
> contain IP addresses and port numbers.  i disagree with the characterization as "admit [...] such a
> weak measure" -- the Security Considerations states the intent and disclaims (with a "MUST NOT") any
> security aspect to it.
> >
> > disagree. the generic (and intentionally open-ended) cryptographic framework is an essential
> semantic aspect of the protocol.  the normative semantics described in this document are common to any
> application of RTMFP.
> >
> >> Hilarie
> >
> > thank you very much.
> >
> > -michael thornburgh

---

From: Michael Thornburgh <[email-masked]>
Date: Tue, 25 Jun 2013 11:49:27 -0700

hi Hilarie, Security Directorate folks.  (note i dropped IESG from the CC list because i already sent a note there)

i have uploaded a new revision -08 of this draft that addresses comments raised during the IETF Last Call, including some of those raised in this thread.

thank you for helping to improve the quality of this document.

-michael thornburgh

> From: Michael Thornburgh
> Sent: Monday, June 24, 2013 11:32 AM
> 	
> this draft describes a generic framework of cryptographic operational semantics with requirements and
> recommendations.  the generic framework is a common part of RTMFP and belongs in this specification.
> specific cryptography choices are left to applications/profiles of RTMFP.  the intention is that
> application-level interoperation would be achieved using this specification and a specification of the
> application-specific Cryptography Profile; for example, a specification describing the Cryptography
> Profile to be used for Flash platform communication.
> 
> as far as two RTMFPs using the same network transport address, think of the different Default Session
> Keys as different spread-spectrum spreading codes.  if used with something like AES-128-CBC, then even
> a "data integrity" check comprising an interior checksum would be enough to reject as corrupt a packet
> using the wrong Default Session Key.
> 
> the Cryptography Profile also determines the method of encryption (Section 2.2.3 first sentence).  in
> the case of Flash communication, this method is AES-128-CBC, and would be fully specified in the
> section 3.5.1.1.2 gives the normative behavior for when an Endpoint Discriminator selects the identity
> of the responder.  see sections 3.5.1.4 and 3.5.1.5 for possible behavior for when an Endpoint
> Discriminator does not select the identity of the responder.
> 
> flow sequence numbers prevent anti-replay (and enable retransmission) within a current flow; however,
> an observer could capture a packet that starts a new flow (using traffic analysis to figure out what
> packet that was), and later, after using traffic analysis to infer that flow is concluded, could
> replay that packet to potentially start a new flow with the same flow ID (or interfere with a new flow
> with the same ID).  i will add something to the Security Considerations about that, to further make
> the case for implementing packet-level anti-replay.
> 
> > Section 2.2.2:
> note that it's not security-by-obscurity because it's documented.  :)  note also that even if it's not
> worth the trouble, it *is* how this deployed protocol actually works.
> 
> disagree. the generic (and intentionally open-ended) cryptographic framework is an essential semantic
> aspect of the protocol.  the normative semantics described in this document are common to any
> application of RTMFP.
> 
> > Hilarie
> 
> thank you very much.
> 
> -michael thornburgh