Last Call Review of draft-ietf-rmt-fcast-07
review-ietf-rmt-fcast-07-secdir-lc-lonvick-2013-01-25-00

Hi,



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 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.






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
...




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:




   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),

   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),




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

CML> the content itself; to corrupt the objects being transmitted.

   These attacks can be launched either:



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


CML> following:




   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.

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:

   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

   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.
CML>
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.


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.


   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.
      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.

   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)"?

   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.

   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...

   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...

   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"?

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...

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...
   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.  :-)

   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...
   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.

   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 (MIC) 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.

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?

   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.

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.

   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