Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

["Maik Seewald (maseewal)" <[e-mail]>]

Hello Ethan,

It looks good!

Thanks.
Maik

From: "Grossman, Ethan A." <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 12. February 2019 at 20:19
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Detnet] DetNet Security Draft Proposed Text - Encryption

Maik,
Also I have paraphrased your earlier proposed additions to the Utilities use case text (as copied from the Use Cases draft for reference) in Appendix A of the Security draft. Here is the text I added, please let me know if you have any corrections or other changes.
          <t>Existing power automation security standards can inform network security. For example
            the NERC CIP (North American Electric Reliability Corporation Critical Infrastructure
            Protection) plan is a set of requirements designed to secure the assets required for
            operating North America's bulk electric system. Another standardized security control
            technique is Segmentation (zones and conduits including access control). </t>

          <t>The requirements in Industrial Automation and Control Systems (IACS) are quite similar,
            especially in new scenarios such as Industry 4.0/Digital Factory where workflows and
            protocols cross zones, segments, and entities. IEC 62443 (ISA99) defines security for
            IACS, typically for installations in other critical infrastructure such as oil and
            gas.</t>

          <t>Availability and integrity are the most important security objectives for the lower
            layers of such networks; confidentiality and privacy are relevant if customer or market
            data is involved, typically handled by higher layers.</t>

FYI All of Appendix A will probably be removed from the Security draft before publication, but during draft development we are keeping it there to provide a single reference point.

Thanks again for your input,
Ethan.

From: Maik Seewald (maseewal) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, February 11, 2019 11:23 PM
To: Grossman, Ethan A. <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Detnet] DetNet Security Draft Proposed Text - Encryption

Hello Ethan,

Only a few comments:

Execution times are essential for flow calculations.
On the other hand, to define bounded execution times is challenging.
And, does it make sense to use the boundary (value) for calculations?

Since this is a new standard, we should recommend agility of crypto algorithms in order to address quantum-safe crypto.
This especially impacts asymmetric algoritms.

Of course, there are implications with symmetric crypto, especially in terms of key management.
But I assume, this won’t be part of the text…

Cheers,
Maik

From: detnet <[e-mail]<mailto:[e-mail]>> on behalf of "Grossman, Ethan A." <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 12. February 2019 at 06:25
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Subject: [Detnet] DetNet Security Draft Proposed Text - Encryption

Hi All,
I have consolidated the list discussion about the pros and cons of encryption algorithms into the Mitigation-Encryption section of the security draft (text of the section as it now reads is below). I would like the WG to review it before I publish it in a new version of the Security draft.
Thanks,
Ethan (as editor of the DetNet Security draft)
--------------------------------------------------------------------
5.    Security Threat Mitigation
5.4.         Encryption
Description
               DetNet flows can be forwarded in encrypted form.
Related attacks
Encryption can be used to mitigate recon attacks (Section 3.2.7). However, for the DetNet to give differentiated quality of service on a flow-by-flow basis, it must be able to identify the flows individually. This implies that in a recon attack the attacker may also be able to track individual flows to learn more about the system.
Encryption can also provide traffic origin verification, i.e. to verify that each packet in a DetNet flow is from a verified source, for example as part of ingress filtering.
5.4.1.     Encryption Considerations for DetNet
Any time spent on encryption and decryption processing (“crypto”) must be included in the flow latency calculations.. Thus, crypto algorithms used in a DetNet must have bounded execution times.
Some crypto algorithms are symmetric in encode/decode time (such as AES and SHA-2) and others are asymmetric (such as public key algorithms). There are advantages and disadvantages to the use of either type in a given DetNet context.
Asymmetrical crypto is typically not used in networks on a packet-by-packet basis due to its computational cost. For example, if only endpoint checks or checks at a small number of intermediate points are required, one can use asymmetric crypto to authenticate distribution or exchange of a secret symmetric crypto key; a successful check based on that key will provide traffic origin verification as long as the key is kept secret by the participants.  Both TLS and IKE (for IPsec) are examples of this for endpoint checks.
However, if we use secret symmetrical keys for this purpose we must give the key to all relays, which increases the probability of a secret key being leaked. Also, if any relay is compromised or misbehaving it may inject traffic into the flow.
Alternatively, asymmetric crypto can provide traffic origin verification at every intermediate node. For example, a DetNet flow can be associated with an (asymmetric) keypair, such that the private key is available to the source of the flow and the public key is distributed with the flow information, allowing verification at every node for every packet. However, this is more computationally expensive.
In either case, origin verification also requires replay detection mechanism as part of the security protocol to prevent an attacker from recording and resending traffic, e.g., as a denial of service attack on flow forwarding resources.