Subject: [Fecframe] Proposed changes to the framework draft - part 2 (security)

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 1 Dec 2010 09:29:34 -0800

This is the 2nd part for the changes we need to make in the framework draft. This part is related to the security issues. Please refer to the tracker to see the comments from the IESG.

https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/

I would like to thank Vincent for providing this brand new security section. I just added a few minor points into the text.

If there are any objections, please speak up. If you are OK with these changes, please also speak up so that we can show WG consensus. 

Thanks,
-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.
   Some of them target the network (e.g., to compromise the routing
   infrastructure by compromising the congestion control component),
   others can target the Content Delivery Protocol (CDP) (e.g., to
   compromise its normal behavior), and finally some attacks target the
   content itself.

   More specifically, these 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 and/or repair flows (e.g., to
      prevent a receiver from using them).

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

   o  They can try to compromise the network's behavior (e.g., by
      causing congestion within the network).

   These attacks can be launched either against the source and/or repair
   flows (e.g., by sending forged 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 a session description).

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 before the FEC protection, or, if done after the FEC
   protection, then this encryption MUST be applied on both the FEC
   source packets and repair packets.  Otherwise, if encryption were to
   be performed only on the FEC source packets after FEC encoding, then
   a non-authorized receiver could be able to recover the source data
   after decoding the repair packets provided that a sufficient number
   of such packets were available.

9.2.2.  Content Corruption

   Protection against corruptions (e.g., after sending 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.  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
   knows 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.
   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 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.
   This approach is documented here to provide a reference of an
   interoperable secure mode of operation.  However, other approaches,
   including other forms of IPsec application, MAY be used or specified
   in the future.

   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: Greg Shepherd <[email-masked]>
Date: Wed, 1 Dec 2010 09:50:26 -0800

Thanks Vincent and Ali!

So far we've had no feedback on the list for these changes. Please
read and respond ASAP - even if you approve please send your approval
to the list. We are so close to finishing up this WG.. let's not
stumble now.

Thanks,
Greg

On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen) <[email-masked]> wrote:
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe
>

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 1 Dec 2010 10:57:03 -0800

I skimmed the new security section and it looks ok to me.  I noticed that
there are some recommendations to use some of the security measures based on
some of the work in the RMT wg, and on TESLA, etc. One thing that is quite
different in streaming than in object delivery (focus of RMT) is that the
startup delay at the client (and the end-to-end-delay) is a crucial concern
for streaming, whereas it is not so much for object delivery.  I haven't
checked and presumably there aren't issues, but perhaps it should be
discussed in the security section (and checked against some of the proposed
solution) that, if possible, any security added should impact the potential
startup delay (and the end-to-end delay) of the client as little as
possible?  Startup delay is the time from when a user decides to watch a
stream till it shows up on the screen.

On 12/1/10 9:50 AM, "Greg Shepherd" <[email-masked]> wrote:

>> This is the 2nd part for the changes we need to make in the framework draft.
>> This part is related to the security issues. Please refer to the tracker to
>> see the comments from the IESG.
>> 
>> I would like to thank Vincent for providing this brand new security section.
>> I just added a few minor points into the text.
>> 
>> If there are any objections, please speak up. If you are OK with these
>> changes, please also speak up so that we can show WG consensus.
>> 
>> Thanks,
>> -acbegen
>> 
>> 
>> 
>>

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 1 Dec 2010 11:07:05 -0800

Actually, maybe the way to think about this is that if the security added to
the solution degrades the user experience (in terms of either the startup
delay or the end-to-end delay) then it can be viewed as an attack on the
service.  One would want a security that doesn't compromise these aspects
even when there is no attack.  But, there could also be attacks on the
security, where the attack attempts to delay the client security
verification, and thus although the security is still there, the attack
slows down the startup delay or the end-to-end delay.  Perhaps both of these
are worth considering/commenting on (both = (1) providing security that
doesn't negatively impact startup/end-to-end delay; (2) discussing attacks
on security that could negatively impact user experience, such as
startup/end-to-end delay).

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 1 Dec 2010 12:06:23 -0800

Hi Mike,

> -----Original Message-----
> From: Luby, Michael [mailto:[email-masked]]
> Sent: Wednesday, December 01, 2010 2:07 PM
> To: Luby, Michael; Greg Shepherd; Ali C. Begen (abegen)
> Cc: [email-masked]
> Subject: Re: [Fecframe] Proposed changes to the framework draft - part 2 (security)
> 

Agree but security is something decided upon before the content is actually delivered. So, when deciding on the method, they will take into account whether delay-wise there is any problems.

> startup/end-to-end delay).

Ok, should we just mention these? Are we recommending anything at all?

-acbegen

---

From: Vincent Roca <[email-masked]>
Date: Wed, 08 Dec 2010 10:53:28 +0100

Hello Mike,

Thanks a lot for your feedback. My answers:

- the new security section mentions the possibility of using TESLA
    within SRTP. It is therefore different from my RFC that describes
    how to use TESLA within RMT protocols, even if the basic idea
    is identical. Additionally, it's merely an example, not the
    recommended solution: the "baseline security solution" relies on
    IPsec/ESP.

- Concerning the delay introduced by TESLA/SRTP, it is currently said:
         "Yet, checking a packet requires a small delay (a second or 
more) after
          its reception with TESLA."
   I suggest to add:
         "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 may degrade the user
          experience. In other situations this will not be an issue."

    In any case, as reminded by Ali, FECFRAME is agnostic WRT the upper
    application and will be used with non real time flows as well. So it's
    not necessarily an issue.

- No matter the provided security mechanisms, attacks that negatively
    impact the user experience (e.g. startup / e2e delay) may exist.
    Imagine an attacker capable of delaying all the traffic sent by the
    source (e.g. by taking control of a forwarding device, by modifying
    the routing path, etc.). The fundamental question here is what is the
    threat model and what do we want to address?
    However I don't think this document has to provide an exhaustive
    analysis and we need to acknowledge that a powerfull attacker
    will cause a lot of dammage... but the receivers will in any case
    identify attacks and mitigate them when feasible, dropping corrupted
    contents, etc. That's the goal.

Hope this makes sense.
Cheers,

    Vincent

On 01/12/10 21:06, Ali C. Begen (abegen) wrote:
>> On 12/1/10 10:57 AM, "Luby, Michael"<[email-masked]>  wrote:
>>
>>> On 12/1/10 9:50 AM, "Greg Shepherd"<[email-masked]>  wrote:
>>>
>>>> Thanks Vincent and Ali!
>>>>
>>>> On Wed, Dec 1, 2010 at 9:29 AM, Ali C. Begen (abegen)<[email-masked]>
>>>> wrote:

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 8 Dec 2010 16:20:21 -0800

Thanks Vincent, this is all fine.  One other thing: does the security part
of the document say anything about the order in which FEC encoding/decoding
is performed relative to security/encryption?  This is one issue that is
specific to FECFRAME, and that is whether encryption should be applied
before/after FEC encoding at the sender and whether decryption should be
applied after/before FEC decoding at the receiver.  Does it make sense to
recommend the former over the latter, as if the latter is used then the FEC
decoding would have to be done in a trusted environment to uphold commonly
desired security properties, which could be quite a burden in many
architectures?

On 12/8/10 1:53 AM, "Vincent Roca" <[email-masked]> wrote:

>> Agree but security is something decided upon before the content is actually
>> delivered. So, when deciding on the method, they will take into account
>> whether delay-wise there is any problems.
>>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 8 Dec 2010 18:32:05 -0800

I got Vincent's additional text into the revision. Regarding your question below:

> Sent: Wednesday, December 08, 2010 7:20 PM
> To: Vincent Roca; Ali C. Begen (abegen)
> Cc: Greg Shepherd; [email-masked]; Luby, Michael

The current text (in the revision to be submitted soon) says:

<quote>
Note that when encryption is applied, this encryption MUST either be applied before the FEC protection, or, if done after the FEC protection, then this encryption MUST be applied on both the FEC source packets and repair packets. Otherwise, if encryption were to be performed only on the FEC source packets after FEC encoding, then a non-authorized receiver could be able to recover the source data after decoding the repair packets provided that a sufficient number of such packets were available.
</quote>

So, we mention both possibilities but do not recommend one over the other. I think the text here is sufficient to say that doing encryption after fec encoding also requires encrypting the FEC packets (which is clearly an additional task which could have been avoided otherwise). Does this require further text?

-acbegen

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 8 Dec 2010 22:41:45 -0500

> So, we mention both possibilities but do not recommend one over the other. I think the text here is sufficient to say that doing encryption after fec encoding also requires encrypting the FEC packe…

I think that this text is very reasonable. WFM.

Regards
Marshall

---

From: "Luby, Michael" <[email-masked]>
Date: Wed, 8 Dec 2010 19:53:03 -0800

I don't think I made the issue very clear, so let me try again.  The issue
is that if decryption happens before FEC decoding then since the media is in
plaintext at this point, the FEC decoding operations must occur in a trusted
environment, since if a bad guy can control or have access to the process
that does the FEC decoding then the bad guy can steal the original media.
If instead decryption happens after FEC decoding then the FEC is operating
on ciphertext, so the FEC decoding operations don't have to occur in a
trusted environment, since if a bad buy can control or have access to the
process that does the FEC decoding then the bad guy is only able to steal
encrypted media.

Perhaps rewording the above appropriately and making this clear is enough.
In any case, it is an extra security risk unique to FEC in this context.

On 12/8/10 7:41 PM, "Marshall Eubanks" <[email-masked]> wrote:

>> Note that when encryption is applied, this encryption MUST either be applied
>> before the FEC protection, or, if done after the FEC protection, then this
>> encryption MUST be applied on both the FEC source packets and repair packets.
>> Otherwise, if encryption were to be performed only on the FEC source packets
>> after FEC encoding, then a non-authorized receiver could be able to recover
>> the source data after decoding the repair packets provided that a sufficient
>> number of such packets were available.
>> </quote>
>> 
>> So, we mention both possibilities but do not recommend one over the other. I
>> think the text here is sufficient to say that doing encryption after fec
>> encoding also requires encrypting the FEC packets (which is clearly an
>> additional task which could have been avoided otherwise). Does this require
>> further text?
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 8 Dec 2010 23:06:33 -0500

Ok got it. Will summarize this after the text below. Thanks for the note. 

-acbegen

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 8 Dec 2010 23:33:08 -0500

> process that does the FEC decoding then the bad guy is only able to steal

Ah, yes, I remember discussion of this. This also means that the encryption of the FEC data (in the decrypt first mode)
needs to be at least as cryptographically secure as the encryption of the original data.

It makes no sense (to take an extreme example) to use a PKI on the data and rot13 on the FEC.

Regards
Marshall

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 06:37:51 -0800

Here is the revised text:

Note that when encryption is applied, this encryption MUST either be applied on the FEC source packets before the FEC protection, or if done after the FEC protection, then both the FEC source packets and repair packets MUST be applied encryption (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, then a non-authorized receiver could be able to recover the source data after decoding the repair packets provided that a sufficient number of such packets were available.
 
The following considerations apply when choosing where to apply encryption. If encryption is applied after FEC encoding on the FEC source and repair packets, decryption will take place before FEC decoding. Since the source and repair data will be in plaintext at this point, the subsequent FEC decoding operations MUST occur in a trusted environment. Conversely, if encryption is applied before FEC encoding on the FEC source packets only, the decryption will take place after FEC decoding. Thus, the FEC decoding operations do not have to occur in a trusted environment. 

-acbegen

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Ali C. Begen (abegen)
> Sent: Wednesday, December 08, 2010 11:07 PM
> To: Luby, Michael
> Cc: [email-masked]
> Subject: Re: [Fecframe] Proposed changes to the framework draft - part 2(security)
>

---

From: Vincent Roca <[email-masked]>
Date: Thu, 09 Dec 2010 16:14:40 +0100

Hello everybody,

This discussion is interesting.

I would say that once again the key point here is the "threat model".
If an attacker can get control of the FEC decoding system and does
what Mike suggests, he necessarily has some control of the FECFRAME
endpoint. Two situations need to be considered then:

1/ If this FECFRAME endpoint is the end system (i.e. where the upper
application runs), the attacker can probably do many nasty things,
like modifying the application as well. In that case the two approaches
("encrypt first, then FEC encode" or "FEC encode first, then encrypt
everything") lead to the same result. I don't see a fundamental
difference in intercepting cleartext at the output of the FECFRAME
module or within the application, at the output of the  deciphering
module.

2/ If this FECFRAME endpoint is a middlebox (i.e. the recovered
Source Flow is sent in cleartext to the final remote destination(s)),
in that case the "encrypt first" approach is preferable to the "FEC
encode first" approach. That's obvious! This is why defining the
"threat model" is important.

In any case, the domains where sensitive data is exchanged in
cleartext MUST be secure (by "exchange" I mean either sent over a
network or communicated between various software modules).
There is nothing specific to FECFRAME IMHO but we can add a
paragraph to highlight it. I'll propose some new text...

One thing that is FECFRAME specific is the situation where several
flows with different security requirements are globally protected.
This is discussed in Section 9.4. This section may be further
improved. I need to think it over.

Cheers,

   Vincent

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 9 Dec 2010 10:52:23 -0800

Some comments below.

> endpoint. Two situations need to be considered then:
*** Depends on the scenario.  This is not necessarily true, although it is a
matter of degree.

> module or within the application, at the output of the  deciphering
*** This is actually an interesting case and one I had in mind, i.e., the
end user is the bad guy.  This is where the architecture of the end system
can be very important, i.e., do things in such a way that it is very
difficult for the end user/bad guy to get hold of the plaintext.  If the
plaintext is available in application space then an end user can possibly
hack in and get control.   If the plaintext is not available in application
space, i.e., there are dedicated protected modules on the end device that
the end user does not have access to as the data flows through from
decryption to display, then this in a sense protects the plaintext from the
bad guy, since it is hard/impossible for the end user to hack in and access
the plaintext within the protected modules.  If the FEC decoding occurs
before the decryption then this architecture is a lot harder to support then
if FEC decoding occurs before decryption, i.e., if FEC decoding occurs after
decryption then the FEC decoding cannot live in application space, it has to
live in the protected module space, which can be impossible/undesirable/very
complicated and expensive.

---

From: "Luby, Michael" <[email-masked]>
Date: Thu, 9 Dec 2010 12:28:25 -0800

This seems good.  The only thing perhaps worth adding is that in some cases
there may be encryption both before and after FEC encoding (and
corresponding operations on the receiver side), since the encryption might
be serving different purposes and have different associated trust models.
Not a big change to the below, but right now it reads as if though you
can/should only do one encryption, and I think it should just be a bit more
lenient on this point.

On 12/9/10 6:37 AM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

> on the FEC source packets before the FEC protection, or if done after the FEC
> protection, then both the FEC source packets and repair packets MUST be
> applied encryption (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, then a non-authorized receiver could be
> able to recover the source data after decoding the repair packets provided
> that a sufficient number of such packets were available.
>  
> The following considerations apply when choosing where to apply encryption. If
> encryption is applied after FEC encoding on the FEC source and repair packets,
> decryption will take place before FEC decoding. Since the source and repair
> data will be in plaintext at this point, the subsequent FEC decoding
> operations MUST occur in a trusted environment. Conversely, if encryption is
> applied before FEC encoding on the FEC source packets only, the decryption
> will take place after FEC decoding. Thus, the FEC decoding operations do not
> have to occur in a trusted environment.
> 
> -acbegen
> 
>>>>> applied

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 9 Dec 2010 12:44:22 -0800

Good point, done.

-acbegen

> Sent: Thursday, December 09, 2010 3:28 PM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]

---

From: Vincent Roca <[email-masked]>
Date: Fri, 10 Dec 2010 12:41:02 +0100

Mike,

I agree with your comments: with certain use-cases, having encryption
below FECFRAME may be unpractical. Thanks for the clarification.
So here is some new text, for section 9.2.1 "Access to Confidential 
Content".
It encompasses (and modifies) the new paragraphs sent by Ali yesterday.

A related question: does it still make sense to have the baseline Secure FEC
Framework Operation rely on IPsec/ESP (i.e. below FECFRAME) (section 9.5)
since we know it won't match some use-case requirements? Alternatively,
should we select SRTP, for instance (or something else)?
My point is that since FECFRAME can be used with applications that do not
generate RTP flows, IPsec/ESP makes more sense than SRTP.

Cheers,

    Vincent

<VR: no change in the following paragraph /VR>

<VR: corrected an error in first sentence: FEC source packets ->  source data /VR>

Note that when encryption is required, 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, then 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.

<VR: replaced Ali's paragraph with the following ones: /VR>

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 FECFRAME 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 FECFRAME), 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 preferable.

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

On 09/12/10 19:52, Luby, Michael wrote:
> Some comments below.
>
>
> On 12/9/10 7:14 AM, "Vincent Roca"<[email-masked]>  wrote:
>
>> Hello everybody,
>>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Dec 2010 09:11:40 -0500

Hi,

I think this security text is very good. It clearly describes the
possible issues, and steps to take to mitigate the issues, including
recommended protocols.

I fail to see a mandatory to implement solution, to support minimum
interoperability. If it is in this text, it should be more clearly
marked as mandatory to implement.

If vendor A uses SRTP to protect against content sorruption, and
vendor B uses IPsec, these two implementations will not interoperate.
You are not defining either of these as mandatory-to-implement. Many
vendors might choose to implement neither since neither is mandatory
for compliance. That means an operator might have neither available to
provide protection. 

I don't see a mandatory to implement protocol for protecting the
session description. 

Please see RFC 3365, which requires strong security for IETF
standards. I don't think your text provides for strong security.

This is an excerpt from another conversation that is happening in the
IESG, and the statement has IESG and IAB consensus:
"IETF [...] has negative experience with two standards in the same
general area.  When one vendor implements one standard and another
vendor implements the other standard, there is no interoperability.
The result is two disjoint communities, which is considered a failure
in the IETF." 

David Harrington
Director, IETF Transport Area
[email-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ali C. Begen
(abegen)
> Sent: Wednesday, December 01, 2010 12:30 PM
> To: [email-masked]
> Subject: [Fecframe] Proposed changes to the framework draft - 
> part 2(security)
> 
> This is the 2nd part for the changes we need to make in the 
> framework draft. This part is related to the security issues. 
> Please refer to the tracker to see the comments from the IESG.
> 
>
> 
> I would like to thank Vincent for providing this brand new 
> security section. I just added a few minor points into the text.
> 
> If there are any objections, please speak up. If you are OK 
> with these changes, please also speak up so that we can show 
> WG consensus. 
> 
> Thanks,
> -acbegen
> 
> 
> 
>

---

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

I will let others chime in as well.

For the mandatory security protocol, neither SRTP nor IPsec nor something else makes sense. SRTP could only be mandated for RTP flows *maybe*. Even that I don't know why every FEC application would need to implement security for FEC. For many such applications, the content itself is secured and FEC is dealt separately. IPsec should not be required every time FEC is needed, either. Some FEC applications do not require security at all.

Does fecframe really require a mandatory security solution? 

Does every fecframe application need to protect the session description? BTW, even using SDP is not required for fecframe so I don't understand why we need a mandatory solution to protect the SDP descriptions.

FYI, the text below has been modified based on the list discussion. See other emails on this thread if you need the latest version.

-acbegen

> From: David Harrington [mailto:[email-masked]]
> Sent: Friday, December 10, 2010 9:12 AM
> To: Ali C. Begen (abegen); [email-masked]
> Subject: RE: [Fecframe] Proposed changes to the framework draft - part 2(security)
> 
> Hi,
>

---

From: "Luby, Michael" <[email-masked]>
Date: Fri, 10 Dec 2010 16:24:18 -0800

The security provided for streaming (if used) depends a lot more on the
content and characteristics of the original stream then it does on the FEC
repair added to the stream (if FEC is used): the FEC is a very small part of
the overall consideration, so it would be unusual if the security should be
selected based on the FEC being used (except that of course the security, if
used, should not be incompatible with the FEC -- but this is already
discussed in the document about how FEC can affect an already selected
security solution).

Thus I'm wondering if it makes sense for FECFRAME to define a mandatory
security?  It seems similar to the congestion control issue, i.e., the FEC
is a supplemental component that provides some QoS, and I think the idea
there is that FEC can only add a limited fraction of bandwidth to a stream,
but it is really the stream that defines the rate/congestion control, and
the FEC reacts naturally in response, but the FEC doesn't define a whole new
congestion control because that is really a function of how the original
content in the stream is delivered.

Among the security solutions that would really be used for streaming, the
most likely candidates are DRMs of various sorts with all kinds of different
IPRs.  If we mandate a security solution that would really be used in
practice, there is this issue as well.

On 12/10/10 4:08 PM, "Ali C. Begen (abegen)" <[email-masked]> wrote:

> For the mandatory security protocol, neither SRTP nor IPsec nor something else
> makes sense. SRTP could only be mandated for RTP flows *maybe*. Even that I
> don't know why every FEC application would need to implement security for FEC.
> For many such applications, the content itself is secured and FEC is dealt
> separately. IPsec should not be required every time FEC is needed, either.
> Some FEC applications do not require security at all.
>
> Does every fecframe application need to protect the session description? BTW,
> even using SDP is not required for fecframe so I don't understand why we need
> a mandatory solution to protect the SDP descriptions.
>
> FYI, the text below has been modified based on the list discussion. See other
> emails on this thread if you need the latest version.
>
> -acbegen
>

---

From: "David Harrington" <[email-masked]>
Date: Fri, 10 Dec 2010 19:40:55 -0500

Hi Mike and Ali,

If you want to avoid a mandatory-to-implement security solution, I
think you should document very clearly in the security considerations
section why it makes little sense to have one. The argument in this
email is a good step in the right direction.

David Harrington

> Sent: Friday, December 10, 2010 7:24 PM
> To: Ali C. Begen (abegen); David Harrington; [email-masked]
> >> Subject: RE: [Fecframe] Proposed changes to the framework 
> draft - part
> >> 2(security)
> >>
> >> Hi,
> >>
> >>>    the FEC Framework itself could be subject to attacks, or
could
> >> pose
> >>>    o  They can try to give access to a confidential content
(e.g.,
> >> in
> >>>    o  They can try to corrupt the source and/or repair 
> flows (e.g.,
> >> to
> >>>    flows (e.g., by sending forged FEC source and/or 
> repair packets)
> >> or
> >>>    Repair FEC Payload ID, or in the Explicit Source FEC 
> Payload ID)
> >> or
> >>>    content provider itself, or within the application 
> (for instance
> >> by
> >>>    using the Secure Real-time Transport Protocol (SRTP) 
> [RFC3711]),
> >> or
> >>>    [RFC4303].  If confidentiality is a concern, it is
RECOMMENDED
> >> that
> >>>    provided at the packet level.  In this case, after removing
all
> >> the
> >>>       solutions to check the integrity and authenticate the
source
> >> of
> >>>       service, and does not create any prohibitive processing
load
> >> or
> >>>    a Reed-Solomon FEC scheme (when applicable) will lead 
> a receiver
> >> to
> >>>    authentication/content integrity techniques of Section 
> 9.2.2 can
> >> be
> >>>    used.
> >>>
> >>>    There are also situations where the only insecure domain is
the
> >> one
> >>>    required, an integrity protection SHOULD be provided below
the
> >> FEC
> >>>    solution, based on IPsec/ESP, can be used to provide a
baseline
> >> FEC

---

From: Vincent Roca <[email-masked]>
Date: Mon, 13 Dec 2010 22:47:05 +0100

Hello everybody,

I think we need to distinguish two different sets of security requirements:

1/ end2end, application-level security, independently of FECFRAME:
The upper application may have specific requirements. As already discussed,
if encryption is needed, it's often preferable to do that above FECFRAME.
This is where all types of DRM solutions fit, and SRTP may be useful too
(even if it is restricted to RTP flows).
=> Relying on IPsec/ESP to achieve this end2end security is inappropriate
    (cf. previous discussion whether encryption should happen before FEC
    encoding or not).

2/ because of the use of FECFRAME:
The motivation is that FECFRAME adds new opportunities for attacks (e.g.
by sending forged repair packets). So it makes sense to follow a global
security approach that prevents or mitigates these attacks, independently
of the potential security requirements of individual source flows. This
approach will consider all flows generated by a FECFRAME sender.
=> Relying on IPsec/ESP to achieve this is meaningful. On the opposite,
    security mechanisms that happen above FECFRAME is of little help.
    I don't know if there is another alternative to IPsec? Any idea?

So the two sets of requirements seem complementary to me.

Now there are special cases...
For instance, because the network infrastructure is assumed reasonably
secure (with 3GPP networks, or DVB broadcast networks, etc.) it can make
sense to ignore 2/. Additionally, FECFRAME is probably just one small
component of a much larger protocol stack in many deployments, as Mike
reminded. Defining a mandatory to implement security solution just
because a few repair packets are sent seems strange...

However the guideline (RFC3365) is to be able to use a secure  mode of
operations in all IETF protocols.
My interpretation is that because FECFRAME adds new threats, this security
solution MUST prevent or mitigate these extra threats. So addressing point
2/ is the goal IMHO. When FECFRAME is used in a protected environment
(e.g. 3GPP example above), this secure mode of operation won't be used,
that's all.

---
NB: It reminds me of a recent SecDir discussion whether the fact IPsec
must be available for IPv6 conformance should be relaxed or not.
some lightweight IPv6 terminals will probably never ever include IPsec.
I don't remember if we reached a consensus here, but the situation
is similar. Is it too much of a burden to have this "IPsec/ESP MUST
implement" requirement in FECFRAME as well?
---

Another point... David says:

   "I don't see a mandatory to implement protocol for protecting the
    session description."

The FECFRAME session description generates new opportunities for attacks,
it's obvious. But I don't see how we can mandate a security solution for
something that is sent OOB, using a mechanism that is not defined by our
I-D. If SDP is used, then it's preferable to refer to SDP's Security
Consideration sections (even if this latter fails to mandate a security
solution!).

Regards,

    Vincent

On 11/12/10 01:40, David Harrington wrote:
>> On 12/10/10 4:08 PM, "Ali C. Begen (abegen)"<[email-masked]>
> wrote:

---

From: "Luby, Michael" <[email-masked]>
Date: Mon, 13 Dec 2010 15:59:50 -0800

Vincent,
I'm not really getting the distinction between (1) and (2) below in terms of
being independent of FECFRAME or not, as I don't think that is the axis of
distinction between the examples you list in (1) and (2). All the security
requirements that FECFRAME needs to address are because FECFRAME is being
used, i.e., roughly your category (2) below. FECFRAME is simply an
augmentation of existing delivery protocols that are already being used for
delivering streams of content.  For example, what you list in (1) wrt
whether security is done above/below FECFRAME is only an issue because of
the use of FECFRAME, and the issue is that if FECFRAME is used after
decryption then there is a new vulnerability introduced because of the usage
of FECFRAME and the security model in usage, i.e., if there was no need to
do any processing such as FEC decoding, there would be no issue, and thus
this is very much an issue introduced by the usage of FECFRAME.  This is
similar to the things you've listed in category (2), i.e., there are new
opportunities for attacks to send forged repair packets, exactly because
FECFRAME is being used and there are repair packets sent because of the
usage of FECFRAME which would not have been sent (and vulnerable) if
FECFRAME were not being used.

Perhaps your distinction axis is security attacks in the end-to-end
transport versus security attacks within the end device, this seems to make
sense.  But in both cases, the security attacks that need to be discussed
and dealt with are those that relate specifically to the usage of FECFRAME
and where it might expose vulnerabilities in both contexts, and it seems
appropriate to address both contexts.  BTW, a third axis is the security in
the servers that are adding FECFRAME formatting to the outgoing packets, and
perhaps this should be addressed as well (e.g., the process of adding FEC
repair packets to the stream might be vulnerable to an attack, and thus it
is better if this process doesn't have access to the plaintext content,
etc.)

Mike

---

From: Vincent Roca <[email-masked]>
Date: Wed, 15 Dec 2010 11:58:28 +0100

Mike and everybody,

I think we now agree, it's more a matter presenting things correctly. So
let's try once again (sorry for this long email). There are several 
dimensions
to consider and this is probably what makes the discussion complex:

Dimension 1, the way FECFRAME is used:
U1- FECFRAME is used end-to-end, and is included in the final end-device
U2- FECFRAME is used in middle-boxes, e.g. to protect several source 
flows globally,
    coming from several content servers, and destinated to the same 
remote middle box.

Dimension 2, the threat model:
T1- threats on the end device when FECFRAME is run on the end-device 
(case U1 above):
    the attacker is either the end-user (who may want to access 
protected content) or
    somebody else. In all cases the attacker has access to the end 
device, but not
    necessarily a full control of the end-device since a secure domain 
can exist.
T2- threats on the FECFRAME middle-box when FECFRAME is run on a 
different server
    (case U2 above). An attacker has access to this box.
T3- threats during the end-to-end transport (e.g. Internet). The 
attacker can do
     many different things on the FEC source and repair packets (e.g. 
delay, drop,
     add forged packets, replay).

Dimension 3, the desired security features W.R.T. the use of FECFRAME:
F1- content integrity / source authentication
F2- content confidentiality
F3- DoS mitigation
F4- anti-replay protection

Dimension 4, the security tools:
S1- the various DRM systems, defined out of the context of IETF, some of 
them
     being proprietary and/or subject to IPRs.
S2- SRTP (and SRTCP).
S3- IPsec/ESP.

We agree we only need to focus on topics related to the use of FECFRAME.
Here is a list of such topics:

**Topic 1** Should encryption be applied after or before FEC protection?
Proposed text already discusses this, depending on the way FECFRAME is
used (U1 or U2) and threat model (T1, T2, T3). It is often preferable
to encrypt first, then do FEC processing.

(NB: the proposed text should be sufficient)

**Topic 2** Is SRTP a solution and how should SRTP be used along with 
FECFRAME?
This is a solution in some situations, but FECFRAME impacts the way it
is used:
- When SRTP is used to encrypt the content, we have the same discussion
   as Topic 1- above.
- When SRTP is used only to provide authentication/integrity, we can
   probably use SRTP either above FECFRAME, or below FECFRAME. Using it
   below FECFRAME, on both FEC Source packets and FEC Repair packets has
   the advantage of fulfilling the desired features F1 and F3 (fake
   FEC source/repair packets are filtered).
   BUT this requires (1) we deal with RTP source flows, and (2) FEC Source
   and Repair packets are RTP packets. There are therefore restrictions.

(NB: we need to update the current I-D to add this discussion too)

**Topic 3** Is IPsec a solution and how should it be used along with 
FECFRAME?
Being applied below FECFRAME it secures the whole traffic (FEC Source and
Repair traffic). With the threat model T3 (end2end transport), it's 
appropriate
and provides the desirable features F1 F3 F4 (that are FECFRAME related) 
along
with F2 (but this is independent of FECFRAME).
It can therefore be a "mandatory to implement" security solution IMHO.
The potential issue I see is that it may seem too much of a burden to 
require
mobile terminals to include IPsec, even if not used.

(NB: we need to improve the current I-D)

**Topic 4** What about attacks on the FECFRAME component itself (T1 and T2)?
This is what Mike means if I understand correctly by:
        "BTW, a third axis is the security in the servers that are adding
         FECFRAME formatting to the outgoing packets, and perhaps this 
should
         be addressed as well (e.g., the process of adding FEC repair 
packets
         to the stream might be vulnerable to an attack, and thus it is 
better
         if this process doesn't have access to the plaintext content, 
etc.)"
If F2 is required, it's clear that encryption must have occurred before, 
while
data was still in the secure domain. In fact I don't know if we can do 
anything
else in this case.

**Topic 5** What about attacks on the session description?
David said:

(NB: we need to improve the current I-D)

Is there anything else? Feel free to suggest new topics if needed or
correct me if I made mistakes.

Regards,

   Vincent