Subject: [Fecframe] Revised security section for the framework

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 17 Dec 2010 08:56:36 -0800

Please let us know if these changes are good or if you have comments. We would like to conclude this work soon. 

-acbegen

9.  Security Considerations

   First of all, it must be clear that the application of FEC protection
   to a stream does not provide any kind of security.  On the opposite,
   the FEC Framework itself could be subject to attacks, or could pose
   new security risks.  The goals of this section are to state the
   problem, discuss the risks and identify solutions when feasible.  It
   also defines a mandatory to implement (but not mandatory to use)
   security scheme.

9.1.  Problem Statement

   A content delivery system is potentially subject to many attacks.
   Attacks can target the content, or the CDP, or the network itself,
   with completely different consequences, in particular in terms of the
   number of impacted nodes.

   Attacks can have several goals:

   o  They can try to give access to a confidential content (e.g., in
      case of a non-free content).

   o  They can try to corrupt the source flows (e.g., to prevent a
      receiver from using them), which is a form of DoS attack.

   o  They can try to compromise the receiver's behavior (e.g., by
      making the decoding of an object computationally expensive), which
      is another form of DoS attack.

   o  They can try to compromise the network's behavior (e.g., by
      causing congestion within the network), which potentially impacts
      a large number of nodes.

   These attacks can be launched either against the source and/or repair
   flows (e.g., by sending fake FEC source and/or repair packets) or
   against the FEC parameters that are sent either in-band (e.g., in the
   Repair FEC Payload ID or in the Explicit Source FEC Payload ID) or
   out-of-band (e.g., in the FEC Framework Configuration Information).

   Several dimensions to the problem need to be considered.  The first
   one is the way the FEC Framework is used.  The FEC Framework can be
   used end-to-end, i.e., it can be included in the final end-device
   where the upper application runs; or the FEC Framework can be used in
   middleboxes, for instance, to globally protect several source flows
   exchanged between two or more distant sites.

   A second dimension is the threat model.  When the FEC Framework
   operates in the end-device, this device (e.g., a personal computer)
   might be subject to attacks.  Here, the attacker is either the end-
   user (who might want to access confidential content) or somebody
   else.  In all cases the attacker has access to the end-device, but
   not necessarily to the full control of the end-device (a secure
   domain can exist).  Similarly, when the FEC Framework operates in a
   middlebox, this middlebox can be subject to attacks or the attacker
   can gain access to it.  The threats can also concern the end-to-end
   transport (e.g., through Internet).  Here, examples of threats
   include the transmission of fake FEC source or repair packets, the
   replay of valid packets, the drop, delay or misordering of packets,
   and of course traffic eavesdropping.

   The third dimension consists in the desired security services.  Among
   them, the content integrity and sender authentication services are
   probably the most important features.  We can also mention DoS
   mitigation, anti-replay protection or content confidentiality.

   Finally, the fourth dimension consists in the security tools
   available.  This is the case of the various Digital Rights Management
   (DRM) systems, defined out of the context of the IETF and that can be
   proprietary solutions.  Otherwise SRTP and IPsec/ESP are two tools
   that can turn out to be useful in the context of the FEC Framework.
   Note that using SRTP requires that the application generates RTP
   source flows and, when applied below the FEC Framework, that both the
   FEC source and repair packets to be regular RTP packets.  Therefore
   SRTP is not considered as a universal solution applicable in all use
   cases.

   In the following sections, we further discuss security aspects
   related to the use of the FEC Framework.

9.2.  Attacks Against the Data Flows

9.2.1.  Access to Confidential Content

   Access control to the source flow being transmitted is typically
   provided by means of encryption.  This encryption can be done by the
   content provider itself, or within the application (for instance by
   using the Secure Real-time Transport Protocol (SRTP) [RFC3711]), or
   at the network layer, on a per-packet basis when IPsec/ESP is used
   [RFC4303].  If confidentiality is a concern, it is RECOMMENDED that
   one of these solutions is used.  Even if we mention these attacks
   here, they are neither related to nor facilitated by the use of FEC.

   Note that when encryption is applied, this encryption MUST either be
   applied on the source data before the FEC protection, or if done
   after the FEC protection, then both the FEC source packets and repair
   packets MUST be encrypted (and an encryption at least as
   cryptographically secure as the encryption applied on the FEC source
   packets MUST be used for the FEC repair packets).  Otherwise, if
   encryption were to be performed only on the FEC source packets after
   FEC encoding, a non-authorized receiver could be able to recover the
   source data after decoding the FEC repair packets provided that a
   sufficient number of such packets were available.

   The following considerations apply when choosing where to apply
   encryption (and more generally where to apply security services
   beyond encryption).  Once decryption has taken place, the source data
   is in plaintext.  The full path between the output of the deciphering
   module and the final destination (e.g., the TV display in case of a
   video) MUST be secured, in order to prevent any unauthorized access
   to the source data.

   When the FEC Framework endpoint is the end system (i.e., where the
   upper application runs) and if the threat model includes the
   possibility that an attacker has access to this end system, then the
   end system architecture is very important.  More precisely, in order
   to prevent an attacker to get hold of the plaintext, all processings,
   once deciphering has taken place, MUST occur in a protected
   environment.  If encryption is applied after FEC protection at the
   sending side (i.e., below FEC Framework), it means that FEC decoding
   MUST take place in the protected environment.  With certain use
   cases, this MAY be complicated or even impossible.  In that case
   applying encryption before FEC protection is preferred.

   When the FEC Framework endpoint is a middlebox, the recovered source
   flow, after FEC decoding, SHOULD NOT be sent in plaintext to the
   final destination(s) if the threat model includes the possibility
   that an attacker eavesdrops the traffic.  In that case also it is
   preferred to apply encryption before FEC protection.

   In some cases, encryption could be applied both before and after the
   FEC protection.  The considerations described above still apply in
   such cases.

9.2.2.  Content Corruption

   Protection against corruptions (e.g., against forged FEC source/
   repair packets) is achieved by means of a content integrity
   verification/source authentication scheme.  This service is usually
   provided at the packet level.  In this case, after removing all the
   forged packets, the source flow might sometimes be recovered.
   Several techniques can provide this content integrity/source
   authentication service:

   o  At the application layer, SRTP [RFC3711] provides several
      solutions to check the integrity and authenticate the source of
      RTP and RTCP messages, among other services.  For instance,
      associated to the Timed Efficient Stream Loss-Tolerant
      Authentication (TESLA) [RFC4383], SRTP is an attractive solution
      that is robust to losses, provides a true authentication/integrity
      service, and does not create any prohibitive processing load or
      transmission overhead.  Yet, checking a packet requires a small
      delay (a second or more) after its reception with TESLA.  Whether
      this extra delay, both in terms of startup delay at the client and
      end-to-end delay, is appropriate or not depends on the target use
      case.  In some situations, this might degrade the user experience.
      In other situations, this will not be an issue.  Other building
      blocks can be used within SRTP to provide content integrity/
      authentication services.

   o  At the network layer, IPsec/ESP [RFC4303] offers (among other
      services) an integrity verification mechanism that can be used to
      provide authentication/content integrity services.

   It is up to the developer and the person in charge of deployment, who
   know the security requirements and features of the target application
   area, to define which solution is the most appropriate.  Nonetheless
   it is RECOMMENDED that at least one of these techniques is used.

   Note that when integrity protection is applied, it is RECOMMENDED
   that it takes place on both FEC source and repair packets.  The
   motivation is to avoid corrupted packets to be considered during
   decoding, which would often lead to a decoding failure or result in a
   corrupted decoded source flow.

9.3.  Attacks Against the FEC Parameters

   Attacks on these FEC parameters can prevent the decoding of the
   associated object.  For instance, modifying the finite field size of
   a Reed-Solomon FEC scheme (when applicable) will lead a receiver to
   consider a different FEC code.

   It is therefore RECOMMENDED that security measures are taken to
   guarantee the FEC Framework Configuration Information integrity.
   Since the FEC Framework does not define how the FEC Framework
   Configuration Information is communicated from sender to receiver, we
   cannot provide further recommendations on how to guarantee its
   integrity.  However, any complete CDP specification MUST give
   recommendations on how to achieve it.  When the FEC Framework
   Configuration Information is sent out-of-band, e.g., in a session
   description, it SHOULD be protected, for instance, by digitally
   signing it.

   Attacks are also possible against some FEC parameters included in the
   Explicit Source FEC Payload ID and Repair FEC Payload ID.  For
   instance, modifying the Source Block Number of an FEC source or
   repair packet will lead a receiver to assign this packet to a wrong
   block.

   It is therefore RECOMMENDED that security measures are taken to
   guarantee the Explicit Source FEC Payload ID and Repair FEC Payload
   ID integrity.  To that purpose, one of the packet-level source
   authentication/content integrity techniques of Section 9.2.2 can be
   used.

9.4.  When Several Source Flows are to be Protected Together

   When several source flows, with different security requirements, need
   to be FEC protected jointly, within a single FEC Framework instance,
   then each flow MAY be processed appropriately, before the protection.
   For instance, source Flows that require access control MAY be
   encrypted before they are FEC protected.

   There are also situations where the only insecure domain is the one
   over which the FEC Framework operates.  In that case, this situation
   MAY be addressed at the network layer, using IPsec/ESP (see
   Section 9.5), even if only a subset of the source flows have strict
   security requirements.

   Since the use of FEC Framework should not add any additional threat,
   it is RECOMMENDED that the FEC Framework aggregate flow be in line
   with the maximum security requirements of the individual source
   flows.  For instance, if denial-of-service (DoS) protection is
   required, an integrity protection SHOULD be provided below the FEC
   Framework, using for instance IPsec/ESP.

   Generally speaking, whenever feasible, it is RECOMMENDED to avoid FEC
   protecting flows with totally different security requirements.
   Otherwise, an important processing would be added to protect the
   source flows that do not need it.

9.5.  Baseline Secure FEC Framework Operation

   This section describes a baseline mode of secure FEC Framework
   operation based on the application of the IPsec security protocol,
   which is one possible solution to solve or mitigate the security
   threats introduced by the use of the FEC Framework.

   Two related documents are of interest.  First, Section 5.1 of
   [RFC5775] defines a baseline secure ALC operation for sender-to-group
   transmissions, assuming the presence of a single sender and a source-
   specific multicast (SSM) or SSM-like operation.  The proposed
   solution, based on IPsec/ESP, can be used to provide a baseline FEC
   Framework secure operation, for the downstream source flow.

   Second, Section 7.1 of [RFC5740] defines a baseline secure NORM
   operation, for sender-to-group transmissions as well as unicast
   feedbacks from receivers.  Here, it is also assumed there is a single
   sender.  The proposed solution is also based on IPsec/ESP.  However,
   the difference with respect to the first document relies on the
   management of IPsec Security Associations (SA) and corresponding
   Security Policy Database (SPD) entries, since NORM requires a second
   set of SA and SPD to be defined to protect unicast feedbacks from
   receivers.

   The FEC Framework has been defined in such a way to be independent
   from the application that generates source flows.  Some applications
   might use purely unidirectional flows, while other applications might
   also use unicast feedbacks from the receivers.  For instance, this is
   the case when considering RTP/RTCP based source flows.  Depending on
   the specific situation, it is RECOMMENDED that the baseline secure
   FEC Framework operation inherits from [RFC5775] in case of purely
   unidirectional sender-to-group flows, or [RFC5740] in case both
   sender-to-group and unicast feedbacks flows are needed.

   Note that the IPsec/ESP requirements profiles outlined in [RFC5775]
   and [RFC5740] are commonly available on many potential hosts.  They
   can form the basis of a secure mode of operation.  One potential
   limitation, however, is the need for privileged user authorization.
   However, automated key management implementations are typically
   configured with the privileges necessary to affect system IPsec
   configuration.

---

From: Vincent Roca <[email-masked]>
Date: Mon, 20 Dec 2010 16:11:25 +0100

Hello everybody,

FYI the proposed security section below implements the comments I've sent to
the list on Dec 15th. More precisely:

- section 9.1 "Problem statement"
    => Completely rewritten to clarify the various dimensions of the 
problem.

- Topic 1: "Should encryption be applied after or before FEC protection?"
    => Already discussed in the previous version of the security section.

- Topic 2: "Is SRTP a solution and how should SRTP be used along with 
FECFRAME?"
    => Discussed in section 9.1, last but one paragraph, and in section 
9.2.1
    for encryption related aspects.

- Topic 3: "Is IPsec a solution and how should it be used along with 
FECFRAME?"
    => It remains the mandatory to implement (but not mandatory to use)
    security scheme, even if it cannot address all possible needs (like 
application
    level content confidentiality).

- Topic 4: "What about attacks on the FECFRAME component itself?"
    => No change (see my email date Dec 15th for more details).

- Topic 5: "What about attacks on the session description?"
   => we updated the second paragraph of section 9.3 "Attacks against
   the FEC Parameters". Basically, we cannot recommend anything, but
   any complete CDP specification MUST provide recommendations.

Let us know if you have further comments.
Cheers,

   Vincent.

On 17/12/10 17:56, Ali C. Begen (abegen) wrote:
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe