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

[Chris Lonvick <[e-mail]>]

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