In February of this year, the DNP Technical Committee published TB2019-001: “Authentication of individual users is obsolete in DNP3-SA”. This technical bulletin, which was the first work item from the Tech Committee’s Secure Authentication Task Force to be published, was the fruit of two and a half years of work between the moment the Tech Committee decided to remove multi-user support and the moment the document was created, edited, reviewed, etc.

In this post, I will take a close look at what the impact of this document is on existing implementations of DNP3: systems, devices and firmware.

Background

Secure Authentication in DNP3 (DNP3-SA for short) is entirely based on the secrecy of one, symmetric, shared secret called the “Update Key”. This key is used to mutually authenticate between the Master and the Outstation (where the Outstation is DNP terminology for a device in the field somewhere - what other protocols sometimes call a “Slave” or the “Controlled Station” - and the Master is the central controlling device that manages one or more Outstations from, for example, a control center). Because that Update Key is symmetric, and is known to both the Master and the Outstation, it can be used to mutually authenticate these two devices in a device-to-device authentication, but it can’t be used to authenticate anything behind the devices. Particularly, you can’t use a symmetric key like this to individually authenticate a person using the Master’s user interface.

The way DNP3-SA was specified in IEEE Std 1815™-2012 allowed for different “User IDs” to exist over a single DNP3 link, each having its own Update Key. This was designed to implement RBAC and allow for some level of authentication of individual users, but fell short of being able to actually live up to that promise: because the Master had to know each of the Update Keys to establish a session for any one of them, the Master could effectively impersonate any of its users without the user’s knowledge. In other words: on the Outstation’s end, the mutual authentication remained with the Master, never with the user behind the Master.

After much discussion, the DNP Technical Committee decided that it was time to remove this feature from DNP3-SA by obsoleting it in DNP3 SAv5 (the version of DNP3-SA defined in IEEE 1815-2012) and removing it from SAv6 (the next version of DNP3-SA) altogether. The Technical Committee therefore formed a “Cybersecurity and Secure Authentication Task Force”, the “SATF”, at its Face-to-Face meeting in 2016 and that task force, of which I am the Chair, set to work defining the next version of DNP3-SA.

Defining DNP3-SA is very much a collaborative effort: the SATF membership comprises some of the leaders of the industry with regard to communications protocols and cybersecurity in SCADA systems, including the man behind the five preceding versions of DNP3-SA, Grant Gilchrist. None of the members are what you’d call “household names”: I don’t think any of us are likely to be mentioned around any kitchen tables other than our own, but the work these people do, not just in the SATF but in the various IEEE Working Groups, the DNP Technical Committee, and the IEC working groups, shapes much of our modern world behind the scenes. This happens through a process of thoughtful discussion, consensus building, and innovation.

Multi-user support in DNP3-SAv5

The original idea behind multi-user support in SAv5, at least as I understand it, was twofold: first, it was to allow implementation of Role-Based Access Control (RBAC) in the Outstation, and second it was to allow auditing Outstation by logging who was behind certain commands sent to it. Both of these goals are valid goals, but neither of them can truly be implemented by having a Master station use multiple symmetric keys to distinguish between the users it is working for at any given time. To implement this securely, the Master itself would either not have access to the key used to sign the control commands, or would have to be trusted not to use it. Trusting what is essentially a man in the middle (in this case, the Master) with a symmetric key is anathema to the kind of applied paranoia that comes with security.

In order to implement audit trails correctly, one would also need to be able to assign blame for any command. In order to be able to do that, you need to implement non-repudiation, which requires asymmetric cryptography because the commands need to be signed with a non-ephemeral key that can be validated after the fact. With symmetric keys, anyone who holds the key can sign (e.g. create an HMAC) on behalf of the owner. Asymmetric keys don’t have that problem, but DNP3-SA doesn’t use asymmetric keys to sign anything during the session.

Implementing multi-user support in DNP3-SA is not completely impossible, even with TB2019-001: there can still be more than one Master-Outstation Association between a Master and an Outstation, each of which can have different access rights, though it should be clear to system engineers that whichever rights the Master has over any connection, it effectively has the sum total of the access it has over all the associations it’s a part of.

Effects of removing multi-user support from SAv5

With this in mind, let’s turn to TB2019-001 itself. It essentially does three things:

It introduces the notion of a “Master-Outstation Association” and defines this association as the information that identifies a specific link between the Master and the Outstation. The Master-Outstation Association is the “object” to which the Update Key is associated.
It removes the notion of a “User” from Secure Authentication, replacing it with either the Master or the Master-Outstation Association, as appropriate.
It simplifies the protocol for as far as that is possible, especially for data concentrators which no longer need to manage users across DNP objects.

This latter point is probably the least important for IEEE 1815, in part because the parts of the standard that it simplified were essentially never implemented commercially, but it goes with the mantra “as simple as possible, but no simpler” that I tend to adopt for anything security-related.

DNP3 is a SCADA protocol. Essentially, it is concerned with supervisory control and data acquisition and has security “bolted on” as a necessary evil. Because of this, most vendors didn’t actually implement multi-user support in their DNP3-SA implementations: stack vendors did, but device vendors using those stacks did not. As a result, the impact of removing multi-user support from the protocol at this juncture is mitigated:

Customers (Utilities) are advised to not ask for multi-user support from vendors
Vendors no longer have to implement multi-user support
There are no known interoperability issues due to this change (i.e. existing implementations for pre-TB2019-001 DNP3-SA will interoperate with implementations of post-TB2019-001 DNP3 without issue)

In fact, most vendors, whether it be device vendors or stack vendors, don’t have to change a single line of code to implement TB2019-001 because it basically enshrines the expected behavior of devices that don’t implement multi-user support in the spec.

Why go to all the trouble for TB2019-001 if it has so little impact?

TB2019-001 functionally does to things:

It announces to the industry, and specifically to users for DNP3-SA, that multi-user support will be removed from the standard in the next version. As a result of this move, it is also being removed from IEC 62351-5, which specifies Secure Authentication for IEC 60870-5 derivatives.
It lays the ground work for SAv6, introducing the Master-Outstation Association, which is fundamental to SAv6’s security model.

Version 6 of DNP3-SA, which is what the SATF is working on now, brings a large number of changes, including:

moving the DNP3-SA session into its own layer, defining it an independent layer between the Application Layer and the Transport Function in such a way that you could use it to implement secure authentication for other protocols as well
adding the Authorization Management Protocol, which allows the DNP Authority to manage RBAC for the Master-Outstation Association, and manage the system's Master-Outstation Associations
solving the enrolment problem, allowing new devices to be enrolled in the system and showing that they are both authorized and authenticated
managing Update Keys without ever sending them over the wire and without allowing a human to know them

… and more.

Conclusion

The SATF meets every week by teleconference, has a world-wide membership of SCADA protocol and cybersecurity experts, tackles important and difficult technical questions, and is fun! I can honestly say I look forward to the SATF meetings every week.

TB2019-001 is just the beginning.