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

[Michael Thornburgh <[e-mail]>]

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
> 	
> hi Hilarie.  thanks for your review.  comments/replies inline.
> 
> > From: Hilarie Orman [mailto:[e-mail]]
> > Sent: Friday, June 21, 2013 10:05 AM
> >
> > 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.
> 
> 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.
> 
> > 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).
> 
> 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!
> 
> > 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?
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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).
> 
> > I did not see any "MUST" requirements for rejecting data that fails to
> > pass cryptographic checks.
> 
> i will add a statement to that effect in Section 2.2.3 3rd paragraph.
> 
> > 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.
> 
> 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.
> 
> > Is there anti-replay prevention?  I cannot tell.  There are sequence
> > numbers, but they could be spoofed under some definitions of the
> > cryptographic profile.
> 
> 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:
> >    "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.
> 
> 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.
> 
> > 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.
> 
> 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
> > document.
> 
> 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