Re: [secdir] secdir review of draft-ietf-rmt-fcast-07

[Vincent Roca <[e-mail]>]

Hello Chris,

Thanks a lot for your review. Here are our answers.
And sorry for our very long delay.


> 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.
> 
> Overall, I believe that security was addressed fairly well in the document.  I do have some problems with the text in the Security Considerations section.  It would help if the authors would review RFC 4949, "The Internet Security Glossary, v2", and consistently apply the terms throughout the paper.  Along that line, I'm suggesting some corrections for the Security Considerations section, below.  Some are editorial just to make some statements more clear.

I was not aware of this glossary. That's impressive and useful.
Thanks for the pointer.


> I would also recommend that the Working Group perform a quick threat analysis and use that as the basis for addressing the potential weaknesses.  This can be done by referencing BCP72 and creating a list of threats that the WG consider to be significant and describing the mechanisms that would appropriately address them.  The WG may wish to look at Section 2 of RFC 5425 as an example.

We agree, and we already wrote such an I-D:
http://tools.ietf.org/html/draft-ietf-rmt-sec-discussion-07


> Also, the subsection titles in 4.2 and 4.3 could be straightened out. Right now you have:
> 4.2 Attacks Against blahblah
> 4.2.1 Abc
> 4.2.2 Bcd
> ...
> 4.3 Attacks Against otherblahblah
> 4.3.1 Attacks Against Klm
> 4.3.2 Attacks Against Lmn

Done.


> My comments are preceded by "CML%" and my suggested text is preceded by "CML>".
> 
> ===vvv===
> 
> 
> 4.  Security Considerations
> 
> 4.1.  Problem Statement
> 
>   A content delivery system is potentially subject to attacks.  Attacks
>   may target:
> 
> CML> A content deliver system may be subject to attacks that may target the following:

Done.

>   o  the network (to compromise the routing infrastructure, e.g., by
>      creating congestion),
> 
> CML> the network; to compromise the delivery infrastructure (e.g., by
> CML> creating congestion),

Done.

>   o  the Content Delivery Protocol (CDP) (e.g., to compromise the
>      normal behavior of FCAST), or
> 
> CML> the Content Delivery Protocol (CDP); to compromise the delivery
> CML> mechanism (i.e., FCAST in this case),

Done.

>   o  the content itself (e.g., to corrupt the objects being
>      transmitted).
> 
> CML> the content itself; to corrupt the objects being transmitted.

Done.

>   These attacks can be launched either:
> 
> CML> These attacks can be launched against all or any subset of the CML> following:

Done.

>   o  against the data flow itself (e.g., by sending forged packets),
> 
>   o  against the session control parameters (e.g., by corrupting the
>      session description, the CID, the object meta-data, or the ALC/LCT
>      control parameters), that are sent either in-band or out-of-band,
>      or
> 
>   o  against some associated building blocks (e.g., the congestion
>      control component).
> 
>   In the following sections we provide more details on these possible
>   attacks and sketch some possible counter-measures.  We finally
>   provide recommendations in Section 4.5.
> 
> CML> More details on these potential attacks are provided in the following
> CML> sections along with possible counter-measures.  Recommendations are
> CML> made in Section 4.5.

Done.

> 4.2.  Attacks Against the Data Flow
> 
>   Let us consider attacks against the data flow first.  At least, the
>   following types of attacks exist:
> 
> CML> The following types of attacks exist against the data flow:

Done.

>   o  attacks that are meant to give access to a confidential object
>      (e.g., in case of a non-free content) and
> 
> CML> attacks that are meant to gain unauthorized access to a confidential
> CML> object (e.g., obtaining non-free content without purchasing it) and

Done

>   o  attacks that try to corrupt the object being transmitted (e.g., to
>      inject malicious code within an object, or to prevent a receiver
>      from using an object, which is a kind of Denial of Service (DoS)).
> 
> 4.2.1.  Access to Confidential Objects
> 
>   Access control to the object being transmitted is typically provided
>   by means of encryption.  This encryption can be done over the whole
>   object (e.g., by the content provider, before submitting the object
>   to FCAST), or be done on a packet per packet basis (e.g., when IPsec/
>   ESP is used [RFC4303], see Section 4.5).  If confidentiality is a
>   concern, it is RECOMMENDED that one of these solutions be used.
> 
> CML% When you say "typically provided" you're indicating that some other
> CML% solution has been used in the past.  I don't see that prior mechanism
> CML% has been referenced.  On the other hand, if you're indicating that
> CML% some general solution has been applied, and is applicable in this
> CML% solution then I'll recommend the following replacement paragraph.
> CML>
> CML> Modern cryptographic mechanisms can provide access controls to
> CML> transmitted objects.  One way to do this is by encrypting the
> CML> entire object prior to transmission knowing that authenticated
> CML> receivers have the cryptographic mechanisms to decrypt the
> CML> content.  Another mechanism that has been employed is to encrypt
> CML> individual packets using IPsec/ESP [RFC4303] (Section 4.5).  If
> CML> access control is desired, one of these mechanisms is RECOMMENDED
> CML> and should be deployed.

Fully agree. Done.

> CML% In the last sentence, you're suddenly bringing in confidentiality.
> CML% That should be described in a separate paragraph.  Perhaps like
> CML% the following paragraph.
> CML>
> CML> Modern cryptographic services can also provide confidentiality of the
> CML> object being transferred to prevent the content from being reassembled
> CML> by an unauthorized observer.  See section 4.5 if that is desired.

I agree.

NEW:

   Modern cryptographic mechanisms can provide access control to 
   transmitted objects.  One way to do this is by encrypting the entire
   object prior to transmission, knowing that authenticated receivers
   have the cryptographic mechanisms to decrypt the content.  Another
   way is to encrypt individual packets using IPsec/ESP [RFC4303]
   (Section 5.5).  These two technics can also provide confidentiality
   to the objects being transferred.
   
   If access control and/or confidentiality services are desired, one of
   these mechanisms is RECOMMENDED and SHOULD be deployed.


> 4.2.2.  Object Corruption
> 
>   Protection against corruptions (e.g., if an attacker sends forged
>   packets) is achieved by means of a content integrity verification/
>   sender authentication scheme.  This service can be provided at the
>   object level, but in that case a receiver has no way to identify
>   which symbol(s) is(are) corrupted if the object is detected as
>   corrupted.  This service can also be provided at the packet level.
>   In this case, after removing all corrupted packets, the file may be
>   in some cases recovered.  Several techniques can provide this content
>   integrity/sender authentication service:
> 
> CML% An attacker injecting forged packets is not corruption.  From the
> CML% list below, I believe that you want to say something more like the
> CML% following.
> CML>
> CML> 4.2.2 Object Data Integrity
> CML>
> CML> Protection against attacks on the data integrity of the object may
> CML> be achieved by a mechanism agreed upon between the sender and
> CML> receiver that features sender authentication and a method to
> CML> verify that the integrity of the object has remained intact during
> CML> transmission.  This service can be provided at the
> CML> object level, but in that case a receiver has no way to identify
> CML> which symbol(s) is(are) corrupted if the object is detected as
> CML> corrupted.  This service can also be provided at the packet level.
> CML> In some cases, after removing all corrupted packets, the file may be
> CML> recovered.  Several techniques can provide a data integrity service as
> CML> well as a service that provides sender authentication.

Done.

>   o  at the object level, the object can be digitally signed, for
>      instance by using RSASSA-PKCS1-v1_5 [RFC3447].  This signature
>      enables a receiver to check the object integrity, once this latter
> CML% I'd suggest removing ", once this latter has been fully decoded."
> CML% It's not needed.

Done.

>      has been fully decoded.  Even if digital signatures are
>      computationally expensive, this calculation occurs only once per
>      object, which is usually acceptable;
> 
>   o  at the packet level, each packet can be digitally signed
>      [RFC6584].  A major limitation is the high computational and
>      transmission overheads that this solution requires.  To avoid this
>      problem, the signature may span a set of packets (instead of a
>      single one) in order to amortize the signature calculation.  But
>      if a single packets is missing, the integrity of the whole set
>      cannot be checked;
> CML% I'm not real familiar with RFC6584 so I just glanced through it.
> CML% It appears that each mechanism described in that document requires
> CML% a signature per packet.  I may be wrong but I'll ask that you
> CML% review that to ensure that your recommendation of providing a
> CML% signature across a group of packets is correct.

Our sentence is misleading. RFC6584 does not consider signing a
group of packets. It is restricted to a per-packet signature. I've removed
any reference to signing across a group of packets. Good point.


>   o  at the packet level, a Group Message Authentication Code (MAC)
>      [RFC2104][RFC6584] scheme can be used, for instance by using HMAC-
>      SHA-256 with a secret key shared by all the group members, senders
>      and receivers.  This technique creates a cryptographically secured
>      digest of a packet that is sent along with the packet.  The Group
>      MAC scheme does not create prohibitive processing load nor
>      transmission overhead, but it has a major limitation: it only
>      provides a group authentication/integrity service since all group
>      members share the same secret group key, which means that each
>      member can send a forged packet.  It is therefore restricted to
>      situations where group members are fully trusted (or in
>      association with another technique as a pre-check);
> CML% I don't understand that last parenthetical.  What is the meaning of:
> CML% "(or in association with another technique as a pre-check)"?

NEW:

      It is therefore restricted to
      situations where group members are fully trusted, or in
      association with another technique as a pre-check to quickly
      detect attacks initiated by non-group members and discard their
      packets;

>   o  at the packet level, Timed Efficient Stream Loss-Tolerant
>      Authentication (TESLA) [RFC4082][RFC5776] 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;
> CML% I don't like the use of the slash between authentication and
> CML% integrity. ...but that may just be me.  I'd suggest properly
> CML% expanding that.  I also wouldn't use "true" to describe an
> CML% authentication service.  Again, however, that's probably just me.
> CML% Also, I would suggest that you not attempt to say how long it takes
> CML% to perform a validation.  Perhaps reword that last sentence to be:
> CML>
> CML> Yet, a delay is incurred in checking a TESLA authenticated packet
> CML> which may be more than what is desired in some deployments.

Done.

NEW:
   o  at the packet level, Timed Efficient Stream Loss-Tolerant
      Authentication (TESLA) [RFC4082][RFC5776] is an attractive
      solution that is robust to losses, provides an authentication and
      integrity verification service, and does not create any
      prohibitive processing load or transmission overhead.  Yet, a
      delay is incurred in checking a TESLA authenticated packet which
      may be more than what is desired in some use-cases;


>   o  at the packet level, IPsec/ESP [RFC4303] can be used to check the
>      integrity and authenticate the sender of all the packets being
>      exchanged in a session (see Section 4.5).
> 
>   Techniques relying on public key cryptography (digital signatures and
>   TESLA during the bootstrap process, when used) require that public
>   keys be securely associated to the entities.  This can be achieved by
>   a Public Key Infrastructure (PKI), or by a PGP Web of Trust, or by
>   pre-distributing securely the public keys of each group member.
> CML% I'd suggest rewording that last phrase for clarity:
> CML> ,or by securely pre-distributing the public keys...

Done.

>   Techniques relying on symmetric key cryptography (Group MAC) require
>   that a secret key be shared by all group members.  This can be
>   achieved by means of a group key management protocol, or simply by
>   pre-distributing securely the secret key (but this manual solution
>   has many limitations).
> CML% Again, I'd suggest rewording:
> CML> , or simply by securely pre-distributing the secret...

Done.

>   It is up to the developer and deployer, who know the security
>   requirements and features of the target application area, to define
>   which solution is the most appropriate.  In any case, whenever there
>   is any concern of the threat of file corruption, it is RECOMMENDED
>   that at least one of these techniques be used.
> CML% Should that be "object corruption" rather than "file corruption"?

Yes. Done.

> 4.3.  Attacks Against the Session Control Parameters and Associated
>      Building Blocks
> 
>   Let us now consider attacks against the session control parameters
>   and the associated building blocks.  The attacker has at least the
>   following opportunities to launch an attack:
> 
>   o  the attack can target the session description,
> 
>   o  the attack can target the FCAST CID,
> 
>   o  the attack can target the meta-data of an object,
> 
>   o  the attack can target the ALC/LCT parameters, carried within the
>      LCT header or
> 
>   o  the attack can target the FCAST associated building blocks, for
>      instance the multiple rate congestion control protocol.
> 
>   The consequences of these attacks are potentially serious, since they
>   can compromise the behavior of content delivery system or even
>   compromise the network itself.
> CML> ...compromise the behavior of the content...

Done.

> 4.3.1.  Attacks Against the Session Description
> 
>   An FCAST receiver may potentially obtain an incorrect Session
>   Description for the session.  The consequence of this is that
>   legitimate receivers with the wrong Session Description are unable to
> CML> ...wrong Session Descriptors will be unable to...

There's a single Session Description by default, so singular is preferable.

>   correctly receive the session content, or that receivers
> CML> ...receivers will inadvertently...
>   inadvertently try to receive at a much higher rate than they are
>   capable of, thereby possibly disrupting other traffic in the network.
> CML% Just suggestions to keep the same verb tenses.  :-)

Done.

>   To avoid these problems, it is RECOMMENDED that measures be taken to
>   prevent receivers from accepting incorrect Session Descriptions.  One
>   such measure is the sender authentication to ensure that receivers
> CML> ...such measure is sender authentication...

Done.

>   only accept legitimate Session Descriptions from authorized senders.
>   How these measures are achieved is outside the scope of this document
>   since this session description is usually carried out-of-band.
> 
> 4.3.2.  Attacks Against the FCAST CID
> 
>   Corrupting the FCAST CID is one way to create a Denial of Service
>   attack.  For example, the attacker can insert an "FCAST-CID-Complete"
>   meta-data entry to make the receivers believe that no further
>   modification will be done.
> 
>   It is therefore RECOMMENDED that measures be taken to guarantee the
>   integrity and to check the sender's identity of the CID.  To that
>   purpose, one of the counter-measures mentioned above (Section 4.2.2)
>   SHOULD be used.  These measures will either be applied on a packet
>   level, or globally over the whole CID object.  When there is no
>   packet level integrity verification scheme, it is RECOMMENDED to
>   digitally sign the CID.
> 
> 4.3.3.  Attacks Against the Object Meta-Data
> 
>   Corrupting the object meta-data is another way to create a Denial of
>   Service attack.  For example, the attacker changes the MD5 sum
>   associated to a file.  This possibly leads a receiver to reject the
>   files received, no matter whether the files have been correctly
>   received or not.  When the meta-data are appended to the object,
>   corrupting the meta-data means that the Compound Object will be
>   corrupted.
> CML% Welllll.... If the MD5 is changed in transit, then that's a Man in
> CML% the Middle (MIIM) attack and the result is a loss of service since
> CML% there is a recovery mechanism.  A DOS would be more like what's
> CML% described in the Security Considerations section of RFC 5740,
> CML% excessive NACKing, or via replay attacks.

This paragraph has been rewording, taking into account other comments.
It also addresses this remark.

NEW:

   Modifying the object meta-data is another way to launch an attack.
   For example, the attacker may change the message digest associated to
   a file, leading a receiver to reject a file, even if it has been
   correctly received.  More generally, a receiver SHOULD be very
   careful during meta-data processing.  For instance a receiver SHOULD
   NOT try to follow links (e.g., the URI contained in th Content-
   Location meta-data).  As another example, malformed HTTP contents can
   be used as an attack vector and a receiver should take great care.


>   It is therefore RECOMMENDED that measures be taken to guarantee the
>   integrity and to check the sender's identity of the Compound Object.
>   To that purpose, one of the counter-measures mentioned above
>   (Section 4.2.2) SHOULD be used.  These measures will either be
>   applied on a packet level, or globally over the whole Compound
>   Object.  When there is no packet level integrity verification scheme,
>   it is RECOMMENDED to digitally sign the Compound Object.
> CML% Actually, I'd write it up something like the following.
> CML>
> CML> As noted in RFC 2616, a message integrity check is not
> CML> sufficient proof against malicious attacks.  The content-MD5 MIC can
> CML> indicate to a receiver that the meta-data has been inadvertently
> CML> modified in transit,
> CML> but a clever attacker would provide a correct MIC to cover any
> CML> malicious changes made in an attack.  It is therefore RECOMMENDED
> CML> that measures be taken to guarantee the
> CML> integrity and to check the sender's identity of the Compound Object.
> CML> To that purpose, one of the counter-measures mentioned above
> CML> (Section 4.2.2) SHOULD be used.  These measures will either be
> CML> applied on a packet level, or globally over the whole Compound
> CML> Object.  When there is no packet level integrity verification scheme,
> CML> it is RECOMMENDED to digitally sign the Compound Object.

OKAY for the attack were both the content and the MIC are modified.
However in this section we restrict ourselves to meta-data. I don't want
to enter such discussions. The "Security Considerations" section is
already pretty detailed. 

I've changed "file" for "object".

> 4.3.4.  Attacks Against the ALC/LCT and NORM Parameters
> 
>   By corrupting the ALC/LCT header (or header extensions) one can
>   execute attacks on the underlying ALC/LCT implementation.  For
>   example, sending forged ALC packets with the Close Session flag (A)
>   set to one can lead the receiver to prematurely close the session.
>   Similarly, sending forged ALC packets with the Close Object flag (B)
>   set to one can lead the receiver to prematurely give up the reception
>   of an object.  The same comments can be made for NORM.
> 
>   It is therefore RECOMMENDED that measures be taken to guarantee the
>   integrity and to check the sender's identity of each ALC or NORM
>   packet received.  To that purpose, one of the counter-measures
>   mentioned above (Section 4.2.2) SHOULD be used.
> 
> 4.3.5.  Attacks Against the Associated Building Blocks
> 
>   Let us first focus on the congestion control building block that may
>   be used in an ALC or NORM session.  A receiver with an incorrect or
>   corrupted implementation of the multiple rate congestion control
>   building block may affect the health of the network in the path
>   between the sender and the receiver.  That may also affect the
>   reception rates of other receivers who joined the session.
> 
>   When congestion control is applied with FCAST, it is therefore
>   RECOMMENDED that receivers be required to identify themselves as
>   legitimate before they receive the Session Description needed to join
>   the session.  If authenticating a receiver does not prevent this
>   latter to launch an attack, it will enable the network operator to
>   identify him and to take counter-measures.  This authentication can
>   be made either toward the network operator or the session sender (or
>   a representative of the sender) in case of NORM.  The details of how
>   it is done are outside the scope of this document.
> CML% I don't understand that paragraph.  Can you rephrase it?

I have simplified it a lot, removing useless considerations.

NEW:

   When congestion control is applied with FCAST, it is therefore
   RECOMMENDED that receivers be authenticated as legitimate receivers
   before they can join the session.  If authenticating a receiver does
   not prevent this latter to launch an attack, it will enable the
   network operator to easily identify him and to take counter-measures.
   The details of how this is done are outside the scope of this
   document.


>   When congestion control is applied with FCAST, it is also RECOMMENDED
>   that a packet level authentication scheme be used, as explained in
>   Section 4.2.2.  Some of them, like TESLA, only provide a delayed
>   authentication service, whereas congestion control requires a rapid
>   reaction.  It is therefore RECOMMENDED [RFC5775] that a receiver
>   using TESLA quickly reduces its subscription level when the receiver
>   believes that a congestion did occur, even if the packet has not yet
>   been authenticated.  Therefore TESLA will not prevent DoS attacks
>   where an attacker makes the receiver believe that a congestion
>   occurred.  This is an issue for the receiver, but this will not
>   compromise the network.  Other authentication methods that do not
>   feature this delayed authentication could be preferred, or a group
>   MAC scheme could be used in parallel to TESLA to prevent attacks
>   launched from outside of the group.
> 
> 4.4.  Other Security Considerations
> 
>   Lastly, we note that the security considerations that apply to, and
>   are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740] and
>   FEC [RFC5052] also apply to FCAST as FCAST builds on those
>   specifications.  In addition, any security considerations that apply
>   to any congestion control building block used in conjunction with
>   FCAST also applies to FCAST.  Finally, the security discussion of
>   [I-D.ietf-rmt-sec-discussion] also applies here.
> CML% If you have this here, then you do not need sections 4.3.4 and
> CML% 4.3.5, unless you are making different recommendations.  Is that
> CML% the case?  If so, then you'll need to explain the differences.

I'm not happy with the Security Considerations of these documents,
in the sense that it is not structured and discussed in the way I'd like
it to be, at least for some parts of them. But the present document does
not contradict them, of course. I therefore prefer to leave it as it is.
 

> 4.5.  Minimum Security Recommendations
> 
>   We now introduce a mandatory to implement but not necessarily to use
>   security configuration, in the sense of [RFC3365].  Since FCAST/ALC
>   relies on ALC/LCT, it inherits the "baseline secure ALC operation" of
>   [RFC5775].  Similarly, since FCAST/NORM relies on NORM, it inherits
>   the "baseline secure NORM operation" of [RFC5740].  More precisely,
>   in both cases security is achieved by means of IPsec/ESP in transport
>   mode.  [RFC4303] explains that ESP can be used to potentially provide
>   confidentiality, data origin authentication, content integrity, anti-
>   replay and (limited) traffic flow confidentiality.  [RFC5775]
>   specifies that the data origin authentication, content integrity and
>   anti-replay services SHALL be used, and that the confidentiality
>   service is RECOMMENDED.  If a short lived session MAY rely on manual
>   keying, it is also RECOMMENDED that an automated key management
>   scheme be used, especially in case of long lived sessions.
> CML% In my very humble opinion, you should start the Security Considerations
> CML% section with this paragraph.  That will establish a baseline for
> CML% development of FCAST.  The next several parts of the section should
> CML% then look at specific concerns for FCAST.

I prefer having a (long) description of the general issues and possible
counter-measures first, all of them being specific to FCAST. And then,
a description of the MTI recommendations.

This is also what we did for FLUTE (rfc 6726) where it turns out that
the IETF MTI recommendations are not in line with the security framework
defined by 3GPP-MBMS where is it widely deployed. Different use cases
and assumptions lead to different security architectures. That's normal of
course. But it also  makes me believe it's better to stick with the current
organization that puts more emphasizes on the concepts, presented first.


>   Therefore, the RECOMMENDED solution for FCAST provides per-packet
>   security, with data origin authentication, integrity verification and
>   anti-replay.  This is sufficient to prevent most of the in-band
>   attacks listed above.  If confidentiality is required, a per-packet
>   encryption SHOULD also be used.
> 
> 
> ===^^^===
> 
> Regards,
> Chris

In any case, thanks a lot for your detailed review.
Cheers,

   Vincent