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