DNP3 SPECIFICATION

Volume 2, Supplement 1

SECURE AUTHENTICATION

Version 1.00
3 February 2007
DISCLAIMER STATEMENT
DNP Users Group documents and publications are not consensus documents. Information contained in
this and other works has been obtained from sources believed to be reliable, and reviewed by credible
members of the DNP Users Group and/or the DNP Users Group Technical Committee. Neither the DNP
Users Group nor any authors/developers of DNP documentation guarantee, and each such person
expressly disclaims responsibility for ensuring, the accuracy or completeness of any information
published herein, and neither the DNP Users Group nor its authors/developers shall be responsible for any
errors, omissions, or damages arising out of use of this document.
Likewise, while the author/developer and publisher believe that the information and guidance given in
this work serves as an enhancement to users, all parties must rely upon their own skill and judgment when
making use of it. Neither the author nor the publisher assumes any liability to anyone for any loss or
damage caused by any error or omission in the work, whether such error or omission is the result of
negligence or any other cause. Any and all such liability is disclaimed.
This statement was developed by the DNP Users Group Technical Committee and represents the
considered judgment of a group of software developers with expertise in the subject field. The DNP Users
Group is a global forum for users and implementers of the protocol and promotes implementers and
developer information and interaction exchange. This work is published with the understanding that the
DNP Users Group and its authors/developers are supplying information through this publication, not
attempting to render engineering or other professional services. If such services are required, the
assistance of an appropriate professional should be sought. The DNP Users Group is not responsible for
any statements and/or opinions advanced in this publication.

NOTICE OF RIGHTS - DNP USERS GROUP

The contents of this manual are the property of the DNP Users Group. Revisions or additions to the
definition and functionality of the DNP Protocol cannot be made without express written agreement from
the DNP Users Group or its duly authorized party. In addition, no part of this document may be altered or
revised or added to in any form or by any means, except as permitted by written agreement with the DNP
Users Group or a Party duly authorized by the DNP Users Group.
The DNP Users Group has made every reasonable attempt to ensure the completeness and accuracy of
this document. However, the information contained in this manual is subject to change without notice,
and does not represent a commitment on the part of the DNP Users Group. Copies of the latest
documentation are available through the DNP Users web site at www.dnp.org.

TRADEMARK NOTICES
DNP is a trademark of the DNP Users Group. Any brand and product names mentioned in this document
are trademarks or registered trademarks of their respective companies.
Copyright © 1991 – 2007 DNP Users Group. All rights reserved

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 2
 REVISION HISTORY

Version Date Reason for Changes

1.00 3-Feb-2007 Original release.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 3
 Contents
1 Introduction ..............................................................................................................................7
1.1 Purpose ................................................................................................................................7
1.2 References ...........................................................................................................................7
1.3 Threats Addressed ...............................................................................................................8
1.4 General Principles ...............................................................................................................8
1.4.1 Authentication Only .....................................................................................................8
1.4.2 Application Layer Only................................................................................................8
1.4.3 Bi-directional................................................................................................................8
1.4.4 Challenge-Response.....................................................................................................8
1.4.5 Pre-Shared Keys...........................................................................................................9
1.4.6 Backwards Tolerance ...................................................................................................9
1.4.7 Upgradeable .................................................................................................................9
1.4.8 Perfect Forward Secrecy ..............................................................................................9
1.4.9 Multiple Users..............................................................................................................9
1.5 Terms and Definitions.......................................................................................................10
2 Theory of Operation (informative) .........................................................................................11
2.1 Narrative Description ........................................................................................................11
2.1.1 Basic Concepts ...........................................................................................................11
2.1.2 Initiating the Challenge ..............................................................................................11
2.1.3 Responding to the Challenge .....................................................................................12
2.1.4 Authenticating ............................................................................................................12
2.1.5 Authentication failure.................................................................................................12
2.1.6 Aggressive mode........................................................................................................12
2.1.7 Changing keys............................................................................................................13
2.1.7.1 Managing Session Keys .....................................................................................13
2.1.7.2 Managing Update Keys......................................................................................14
2.2 Example Message Sequences............................................................................................14
2.2.1 Overview of Section...................................................................................................14
2.2.2 Challenge of a Critical ASDU....................................................................................14
2.2.3 Periodic Challenge .....................................................................................................15
2.2.4 Aggressive Mode .......................................................................................................16
2.2.5 Initializing and Changing Session Keys.....................................................................18
2.3 State Machine Overview ...................................................................................................19
3 Formal Specification ..............................................................................................................22
3.1 Message Definitions..........................................................................................................22
3.1.1 Master Authentication Implementation......................................................................22
3.1.1.1 Function Code 32 (0x20) Authentication Request.............................................22
3.1.1.2 Function Code 33 (0x21) Authentication Reply ................................................23
3.1.1.3 Function Code 34 (0x22) Authentication Error – No Ack.................................23
3.1.1.4 Use of the Write (0x02) Function Code to Change Session Keys .....................23
3.1.1.5 Use of the Read (0x01) Function Code to Request Key Status .........................23
3.1.2 Outstation Authentication Implementation ................................................................24
3.1.2.1 Function Code 131 (0x83) Authentication Challenge .......................................24
3.1.2.2 Function Code 132 (0x84) Unsolicited Authentication Challenge ....................25
3.1.3 DNP3 Message Examples ..........................................................................................25
3.2 Formal Procedures.............................................................................................................28
3.2.1 Challenger procedures................................................................................................28
3.2.1.1 Challenger Role .................................................................................................28
3.2.1.2 Critical Functions...............................................................................................28

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 4
 3.2.1.3 Authentication Procedures .................................................................................30
3.2.1.4 Challenge Timer.................................................................................................30
3.2.1.5 Challenger State Machine ..................................................................................31
3.2.1.6 Error Messages...................................................................................................34
3.2.2 Responder procedures ................................................................................................34
3.2.2.1 Responder Role..................................................................................................34
3.2.2.2 Responding to Challenges..................................................................................34
3.2.2.3 Aggressive Mode ...............................................................................................34
3.2.3 Master Procedures......................................................................................................34
3.2.3.1 Master Role........................................................................................................34
3.2.3.2 Changing Session Keys......................................................................................34
3.2.3.3 Master State Machine.........................................................................................36
3.2.4 Outstation procedures.................................................................................................37
3.2.4.1 Outstation Role ..................................................................................................37
3.2.4.2 Key Status ..........................................................................................................37
3.2.4.3 Authenticating Session Key Changes ................................................................37
3.2.4.4 Changing Session Keys......................................................................................37
3.2.4.5 Outstation State Machine ...................................................................................38
3.2.5 DNP3 Sequence Numbering ......................................................................................38
4 Interoperability Requirements ................................................................................................41
4.1 Minimum Requirements....................................................................................................41
4.1.1 HMAC Algorithms.....................................................................................................41
4.1.1.1 HMAC-SHA1 ....................................................................................................41
4.1.2 Key Wrap Algorithms ................................................................................................41
4.1.2.1 AES-128 Key Wrap ...........................................................................................41
4.1.3 Fixed values ...............................................................................................................41
4.1.3.1 Minimum session key size .................................................................................41
4.1.3.2 Minimum update key size .................................................................................41
4.1.4 Configurable values ...................................................................................................42
4.1.4.1 Periodic challenge interval.................................................................................42
4.1.4.2 Maximum random challenge interval ................................................................42
4.1.4.3 Response timeout ...............................................................................................42
4.1.4.4 Session Key change interval ..............................................................................42
4.1.4.5 Session Key change count..................................................................................42
4.1.4.6 Expected Session Key change interval and count..............................................42
4.1.4.7 Use of aggressive mode .....................................................................................42
4.1.4.8 Maximum error count ........................................................................................42
4.2 Options ..............................................................................................................................43
4.2.1 HMAC algorithms......................................................................................................43
4.2.1.1 HMAC-SHA256 ................................................................................................43
4.2.2 Key Wrap algorithms .................................................................................................43
5 Special Applications...............................................................................................................44
5.1 Use with the Internet Protocol Suite..................................................................................44
5.2 Use with Redundant Channels ..........................................................................................44
5.3 Use with External Link Encryptors ...................................................................................44
5.4 Use with Data Concentrators.............................................................................................44
5.4.1 Definition of a Data Concentrator..............................................................................44
5.4.2 Authentication Procedures for Data Concentrators....................................................46
6 Compliance with IEC 62351-5 ...............................................................................................48
6.1 Selected options.................................................................................................................48
6.2 Operations Considered Critical .........................................................................................48
6.3 Addressing Information.....................................................................................................48
DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203
3 February 2007 Page 5
 6.4 Message Format Mapping .................................................................................................49
6.5 Reference to Procedures....................................................................................................49

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 6
1 INTRODUCTION

1.1 Purpose
The purpose of this specification is to define a protocol mechanism that:
• A DNP3 outstation can use to unambiguously determine it is communicating with a user who is
authorized to access the services of the outstation.
• A DNP3 master can use to unambiguously determine that it is communicating with the correct
outstation.

1.2 References
This specification is fundamentally based on IEC 62351-5 and is intended to be compliant with that
specification as well as selected portions of ISO/IEC 9798-4. If there are disagreements between this
specification and those references, this specification shall be considered to be correct.

Number Title

IEC 62351-1 Data and Communications Security – Part 1: Introduction

IEC 62351-2 Data and Communications Security – Part 2: Glossary

IEC 62351-3 Data and Communications Security– Part 3: Communication Network and System
Security - Profiles Including TCP/IP

IEC 62351-5 Data and Communications Security – Part 5: Security for IEC 60870-5 and
derivatives

ISO/IEC 9798-4 Information technology – Security techniques – Entity authentication – Part 4:

Mechanisms using a cryptographic check function

RFC 2104 HMAC: Keyed-Hashing for Message Authentication

RFC 3174 Secure Hash Algorithm (SHA-1)

FIPS 186-2 Digital Signature Standard (DSS), USA NIST, February 2000 including Change
Notice #1, October 2001. Only the random number generation algorithms in the
appendix are used.

RFC 3394 Advanced Encryption Standard (AES) Key Wrap Algorithm

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 7
1.3 Threats Addressed
This specification shall address only the following security threats, as defined in IEC 62351 Part 2:
• Spoofing
• Modification
• Replay
• Eavesdropping - on exchanges of cryptographic keys only, not on other data.
• Non-repudiation – to the extent of identifying individual users of the system

1.4 General Principles

This section describes the guiding principles behind this specification, based on the identified threats.

1.4.1 Authentication Only

This specification addresses authentication only, not encryption or other security measures. It does not rule out the
possibility of such measures being added to DNP3 later or through the use of external measures such as “bump in
the wire” link encryptors.

1.4.2 Application Layer Only

This specification describes authentication at the application layer. Application layer authentication is necessary
because:
• DNP3 must be used over a variety of different physical networks and may be “bridged” from one to the
other, as in the case of a TCP/IP terminal server or IP radio. Only authentication at the application layer
will ensure end-to-end security.
• Application layer authentication permits the possibility of protection against “rogue applications” that may
be co-resident with the DNP3 application and attempt to use the DNP3 link without authorization.
• Application layer authentication permits the possibility of authenticating individual users, as discussed in
section 1.4.9.

1.4.3 Bi-directional

This specification describes a mechanism that can be used in either transmission direction, master-to-outstation
(controlling direction) or outstation-to-master (monitoring direction).

1.4.4 Challenge-Response

The mechanism described in this specification is based on the concept of challenge and response. This principle has
been applied for the following reasons:
• It places the responsibility for security on the device that requires authentication, which is more practical in a
diverse network such as those found in the utility industry.
• It permits some communication to be left unsecured if desired, reducing bandwidth and processing
requirements.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 8
• It works effectively in a non-connection-oriented environment.

1.4.5 Pre-Shared Keys

This specification permits pre-shared keys to be used by default. This principle recognizes the fact that many
utilities may choose not to manage security credentials in a more sophisticated manner but nevertheless require
some level of protection.
This specification does not prevent the use of public-key cryptography mechanisms to be used to change or
distribute the pre-shared keys described here. Future specifications may standardize such methods, but they are
currently out of the scope of this specification.

1.4.6 Backwards Tolerance

This specification recommends that the following conditions be satisfied when a secure device (one implementing
this authentication mechanism) communicates with a non-secure device:
• The secure device must be able to detect that the non-secure device does not support the authentication
mechanism.
• The non-secure device must continue to operate normally after being contacted by the secure device. In other
words, the authentication message cannot cause the non-secure device to fail.
• The two devices must be able to continue to exchange information that is not considered critical.
However, the mechanism’s ability to meet these conditions is largely dependent on the quality of the implementation
on any particular device. This specification therefore recommends that secure devices avoid sending security
messages if it is not known whether the remote device supports security.

1.4.7 Upgradeable

This specification permits system administrators to change algorithms, key lengths, and other security parameters to
deal with future requirements. In keeping with the principle of backward tolerance, it also permits one end of a link
to be upgraded at a time.

1.4.8 Perfect Forward Secrecy

This specification follows the security principle of perfect forward secrecy, as defined in IEC 62351 Part 2. If a
session key is compromised, this mechanism only puts data from that particular session at risk, and does not permit
an attacker to authenticate data in future sessions.

1.4.9 Multiple Users

This specification assumes that there may be multiple users of the system located at the site of the master. It
provides a method to authenticate each of the users separately from each other and from the master itself.
The intent of this principle is to permit the outstation to conclusively identify the individual user (not just the device)
that transmits any protocol message. This information can be used in audit logs for non-repudiation purposes,
although such use is out of the scope of this specification.
This specification allows for the possibility that outstations may limit access to certain functions, either based on the
individual identities of users, or based on the “roles” the users perform. However, it does not specify a mechanism
for defining such user-based or role-based access control.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 9
1.5 Terms and Definitions
The terms “master” and “outstation” have their usual DNP3 definitions in this specification.
The following term is inherited from the Open Systems Interconnect model and the IEC 60870-5
specifications:

ASDU Application Service Data Unit. The data presented by the application layer to lower layers
for transmission. Equivalent to a DNP3 application layer fragment.

The following terms are inherited from the IEC 60870-5 specifications:

Control Data transmitted by the master to the outstation.

Direction

Monitoring Data transmitted by the outstation to the master.

Direction

The following terms are described here because they are specific to this authentication mechanism:

Challenger A station that issues authentication challenges. May be either a master or outstation.

Responder A station that responds or reacts to authentication challenges. May be either a master or
outstation.

Message A block of data that is part of the authentication mechanism. It will be expressed by some
combination of DNP3 objects, function codes, qualifiers, etc.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 10
2 THEORY OF OPERATION (INFORMATIVE)
This section describes the operation of the authentication mechanism in general terms for the benefit of first-time
readers. This section is informative only; in the case of disagreements between this section and section 3, section 3
shall be taken as correct.

2.1 Narrative Description

This section describes the operation of the authentication mechanism as a text narrative.

2.1.1 Basic Concepts

The authentication mechanism is based on two concepts:

• A challenge and response protocol, as discussed in section 1.4.4. The general mechanism is illustrated in
Figure 1.
• The concept of a Keyed-Hash Message Authentication Code (HMAC) that both the outstations and masters
calculate based on each Application Service Data Unit (ASDU, or protocol message) that is to be
authenticated.
An HMAC algorithm is a mathematical calculation that takes a protocol message as input, produces a smaller piece
of data as output, and has the following characteristics:
• The value of the output is sensitive to small changes in the input message, so the output of the HMAC can be
used to detect if the message was modified.
• The calculation makes intrinsic use of a secret key that is shared by both ends of the communication.
• It is extremely difficult to determine the secret key by viewing the HMAC output.
This challenge-response mechanism using an HMAC is a “unilateral, two-pass authentication” mechanism as
described in ISO/IEC 9798-4.

2.1.2 Initiating the Challenge

The challenge may be initiated either by the master or the outstation.

Devices shall issue challenges at the following times:
• Initially, to prevent any communications from proceeding without prior authentication.
• Periodically and randomly, to protect against man-in-the-middle attacks. (This includes outstations, using
unsolicited responses if permitted).
• To protect specific ASDUs that the device considers to be critical. The challenger issues the challenge
immediately after receiving the critical ASDU, before taking any action on it.
Outstations shall consider all output operations (controls, setpoint adjustments, parameter settings, etc.) to be
critical. Other mandatory critical operations are described in section 3.2.1.2. Each implementation may define
additional mandatory critical operations.
To protect against replay attacks, the challenge message contains data that changes randomly each time a challenge
is issued.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 11
The challenger specifies in the challenge message the cryptographic Keyed-Hash Message Authentication code
(HMAC) algorithm for the responder to use when building the response.

2.1.3 Responding to the Challenge

The device (either master or outstation) that receives the challenge must respond before communications can
continue.
The responder performs the HMAC algorithm specified in the challenge message to produce the response. A shared
Session Key known to both devices is an integral part of the computation. The following types of information are
included in the computation:
• A number specifying the user on the Master side is included.
• The challenge data is included, to protect against replay attacks.
• If the challenger is protecting a specific critical ASDU, data from that ASDU is also included in the
computation. This protects against modification of the ASDU by an attacker.
The response includes the resulting HMAC value.

2.1.4 Authenticating

Upon receiving the response, the challenger performs the same calculation on the same data used by the responder.
If the results match, the challenger permits communications to continue. If the challenger was protecting a particular
ASDU, it processes the ASDU.

2.1.5 Authentication failure

If the authentication fails, the challenger shall not perform the requested operation. The challenger may then choose
to transmit an error message. To help protect against denial-of-service attacks and attackers learning from repeated
challenges, the challenger shall cease to transmit error messages after a configurable number of failures.

2.1.6 Aggressive mode

To reduce bandwidth usage, a responder attempting a critical operation may optionally “anticipate” the challenge
and send the HMAC Value in the same ASDU being protected. This eliminates the challenge and response
messages. Aggressive mode provides a lower level of security, because not as much data is changing in each
message.
For this reason, aggressive mode is optional in IEC 62351-5. However, the value of aggressive mode is considered
high enough for DNP3 that all DNP3 implementations of this authentication mechanism are required to support it.
Per IEC 62351-5, however, all DNP3 implementations are also required to permit it to be disabled by configuration,
so that individual projects can use only challenge and response if they choose.
Aggressive mode is a “unilateral, one-pass authentication” mechanism as described in ISO/IEC 9798-4. However, it
is somewhat more secure against replay attacks than the mechanism described there, because the Aggressive Mode
Request includes information from the most recently received challenge in addition to the sequence number required
by ISO/IEC 9798-4.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 12
2.1.7 Changing keys

Table 1 summarizes how cryptographic keys are used and updated in this authentication mechanism.
Table 1 – Summary of Keys Used

Type Use Change Mechanism Range of Expected

Change Interval
Monitoring Used to authenticate The master encrypts the Session Key Minutes
Direction data transmitted in the in a Key Change message using the
Session Key monitoring direction by Update Key.
the outstation.
Control Used to authenticate The master encrypts the Session Key Minutes
Direction data transmitted in the in a Key Change message using the
Session Key control direction by the Update Key.
master.
Update Key The master shall use The Update Key is pre-shared by the Months or Years
the Update Key to two devices and is changed only by
periodically change the means external to the protocol.
Session Keys.

2.1.7.1 Managing Session Keys

The Session Keys that each device uses to hash the challenge data are the most frequently used keys. A different
Session Key is used in each direction, so that if the key for one direction is compromised, it does not compromise
communications in the other direction. There is a different set of Session Keys and a different Update Key for each
user at the master end, identified by a User Number.
The master initializes the Session Keys immediately after communications is established and regularly changes the
Session Keys thereafter. This practice of periodically changing the Session Keys protects them from being compro-
mised through analysis of the communications link.
The master uses a second key, called the Update Key, to encrypt the new Session Keys, together with the challenge
data, inside a Key Change message. The use of a second key permits the master to change the Session Key even if
the original Session Key was compromised. Both the Session Keys and the Update Key are symmetric keys.
The sequence for changing the Session Keys is shown in Figure 7 and Figure 8. Like the normal authentication
mechanism, it is also based on challenge and response:
• The master sends a Key Status Request message, which contains no data but serves to initiate the process. It
does include a User Number which indicates the particular Update Key and set of Session Keys being
queried.
• The outstation replies with a Key Status message containing the current status of the keys and some
challenge data.
• The master updates the Session Keys with a Key Change message. Besides changing the keys, the Key
Change message also constitutes a response to the challenge and permits the outstation to authenticate that
the correct entity is attempting to change the Session keys.
• The outstation replies with a new Key Status message. This Key Status message indicates whether the Key
Change was successful (i.e. properly received and authentic) and includes freshly generated challenge data.
• Thereafter, the master can send another Key Change message at any time, replying to the most recent
challenge data it received.
The algorithm used to encrypt both the Session Keys together with the challenge data is known as a “key wrap”
algorithm. The minimum required key wrap algorithms are specified in section 4.1.2.
If either device determines that the link has failed, it shall assume the most recent set of Session Keys have been
compromised and shall refuse to use them to authenticate any further Challenge or Aggressive Mode Request
DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203
3 February 2007 Page 13
messages. The master shall send a Key Status Request at the earliest opportunity after detecting the link failure, and
re-initialize the Session Keys.

2.1.7.2 Managing Update Keys

As discussed in section 1.4.9, this authentication mechanism permits multiple users of the system to be authenticated
separately from the master itself. Each user is identified by his or her own User Number and has his or her own
Update Key and set of Session Keys.
Each user’s Update Key is rarely changed. The reason for such a change is dependent on the security policy of the
organization, but may include the Update Key being compromised, or a user leaving the organization. In such cases
the Update Key must be changed through a mechanism external to the protocol. This mechanism is outside the scope
of this specification, but it must ensure that the Update Key is kept secret and cannot be obtained by eavesdropping
in transit.

2.2 Example Message Sequences

2.2.1 Overview of Section

This section contains diagrams illustrating examples of how the authentication mechanism shall behave. This section
is informative only. Refer to section 3 for a formal description of the mechanism. Bold arrows in these diagrams
represent authentication-specific messages.

2.2.2 Challenge of a Critical ASDU

Figure 1and Figure 2 illustrate the challenge and response to a Critical ASDU.

Figure 1 – Example of Successful Challenge of Critical ASDU

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 14
 Figure 2 – Example of Failed Challenge of Critical ASDU

2.2.3 Periodic Challenge

Figure 3 and Figure 4 illustrate a periodic challenge not related to a Critical ASDU.

Figure 3 – Example of a Successful Periodic Challenge

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 15
 Figure 4 – Example of a Failed Periodic Challenge

2.2.4 Aggressive Mode

Figure 5 and Figure 6 illustrate authentication of a Critical ASDU using Aggressive Mode.

Responder Challenger

Non-Critical ASDU

Standard protocol response

Process
ASDU
Aggressive M
ode Request
including Critic
al ASDU

Authenticate

Standard protocol response

Process ASDU

Figure 5 – Example of a Successful Aggressive Mode Request

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 16
 Figure 6 – Example of a Failed Aggressive Mode Request

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 17
2.2.5 Initializing and Changing Session Keys

Figure 7 and Figure 8 illustrate how the master initializes and changes the Session Keys on startup, periodically, and
after a link failure.

Figure 7 – Example of Session Key Initialization and Periodic Update

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 18
 Figure 8 - Example of Link Failure Followed by Session Key Change

2.3 State Machine Overview

Figure 9 and Figure 10 show the major state transitions for the protocol. These diagrams are not normative, nor are
they comprehensive. However, these figures are intended to show the general operation of the authentication
protocol.
The details of the state machines are specified in section 3. If these diagrams differ from section 3, that section shall
be considered to be correct.
The Security Idle and Wait for Response states are common to both masters and outstations. The other states are
specific to each type of device.
For simplicity, these figures show a transition to the Wait for Response state upon receiving an Aggressive Mode
Request. In reality, as described in Table 5, this transition would be only momentary and the device would
immediately return to Security Idle state after taking the appropriate action.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 19
 Response Timeout OR
Rx Invalid Response and Wait for
Err Count Exceeded / Response
Tx Key Status Req

Rx Valid
Rx Invalid Rx Critical Rx Aggressive
Key Status Response /
Key Status <> OK, OR Response / ASDU OR Mode Request /
Timeout / Tx normal
Response Timeout / Tx Error & Challenge
Tx Key protocol Treat like
Tx Key Status Req Increment Timeout / challenge and
Status Req Wait for Error Count Tx Challenge immediate
Key
response
Status
Response Timeout /
Tx Key Tx Key Change
Status Req
Security
Wait for Key
Idle
Change Rx Non-
Init Confirmation Critical
Rx Key Status / ASDU /
Tx Key Change Tx normal
Rx Key Status = OK / protocol
Mark next ASDU critical Rx Challenge /
Tx Response

Link Failure Detected /

Tx Key Status Req

Figure 9 – Major State Transitions for Master

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 20
 Figure 10 – Major State Transitions for Outstation

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 21
3 FORMAL SPECIFICATION
This section formally describes the protocol used for this authentication mechanism. If this section differs from
section 2, this section shall be considered to be definitive.

3.1 Message Definitions

This section describes the DNP3 messages used to implement the authentication mechanism. The DNP3
objects used are defined in attached Data Object Library insert sheets.

3.1.1 Master Authentication Implementation

DNP3 masters shall implement the authentication mechanism using the function codes and objects described in
Table 2. The first column of the table shows how these function codes and objects correspond to the IEC 62351-5
specification and the state machines in section 3.2.
Table 2 – DNP3 Master Messages with Correlation to IEC 62351-5
IEC 62351-5 Description DNP3 Function DNP3 object
Message Code(s)
Challenge Requires authentication of the 0x20 Authentication Group 120, Variation 1 (g120v1)
Message previous DNP3 Response or Request Authentication Challenge object
Unsolicited Response
Response Provides authentication of the 0x21 Authentication Group 120, Variation 2 (g120v2)
Message previous DNP3 Request as required Reply Authentication Reply object
by the outstation
Aggressive Provides authentication for the Whatever function Group 120, Variation 3 (g120v3)
Mode Request current DNP3 Request code is in the DNP3 Authentication Aggressive Mode
Message Request. Request object
Key Status Requests from the outstation the 0x01 Read Group 120, Variation 4 (g120v4)
Request current status of the Session Keys. Session Key Status Request object
Message
Key Change Changes the symmetric Session 0x02 Write Group 120, Variation 6 (g120v6)
Message Keys subsequently used by master Session Key object
and outstation for authentication.
Error Message Indicates the authentication Ox22 Authentication Group 120, Variation 7 (g120v7)
provided in the previous DNP3 Error Authentication Error object
Response was incorrect

The function codes specific to the authentication mechanism are defined in the following sections:

3.1.1.1 Function Code 32 (0x20) Authentication Request

The master uses this function code to issue an authentication challenge to the outstation. In other words, it requests
that the outstation authenticate the most recent DNP3 response or unsolicited response message transmitted by the
outstation.
The DNP3 request message contains a valid Authentication Challenge object, and the DNP3 response message
contains an Authentication Reply object. Rules are applied as in section 3.2 with the DNP3 master acting as the
Challenger

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 22
Each fragment of a multi-fragment Response shall be challenged individually. If a master issues a challenge to a
multi-fragment response (function codes 129 or 130) from an outstation, it shall issue a challenge for each fragment
in the response.

3.1.1.2 Function Code 33 (0x21) Authentication Reply

The master uses this function code to reply to an authentication challenge by the outstation.
The DNP3 request message contains an Authentication Reply object. The DNP3 response message may optionally
contain an Authentication Error object, or may be a null response. A null response with no IIN error bits set
indicates that the Authentication Reply was correct. Rules are applied as in section 3.2, with the DNP3 master acting
as the Responder.

3.1.1.3 Function Code 34 (0x22) Authentication Error – No Ack

The master uses this function code to tell the outstation that it supplied an incorrect Authentication Reply object or
that some other error has occurred.
The DNP3 request message contains an Authentication Error object. There is no DNP3 response message for this
DNP3 request. Rules are applied as in section 3.2, with the DNP3 master acting as the Challenger.
If the Maximum Error Count for the authentication mechanism has been exceeded, the master may choose not to
send this function code.

3.1.1.4 Use of the Write (0x02) Function Code to Change Session Keys
The master shall use the Write function code to change the Session Keys using the Session Key object. The DNP3
response shall include a Session Key Status object. Rules are applied as in section 3.2.

3.1.1.5 Use of the Read (0x01) Function Code to Request Key Status
The master shall use the Read function code to read the current status of the Session Keys as understood by the
outstation. The DNP3 request message contains only the Session Key Status Request object. The outstation
transmits a response containing a Session Key Status object. Rules are applied as in section 3.2.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 23
3.1.2 Outstation Authentication Implementation

DNP3 outstations shall implement the authentication mechanism using the function codes, objects, and Internal
Indications described in Table 3. The first column shows how they correspond to the IEC 62351-5 specification and
the state machines in section 3.2 Note that the Challenge Message has the Parameter Error internal indication bit set.
The outstation sets this bit so that a non-secure device receiving the message will receive notice that the previous
Request sent by the master was not accepted.

Table 3 – DNP3 Outstation Messages with Correlation to IEC 62351-5

IEC 62351-5 Description DNP3 Function DNP3 Object DNP3
Message Code(s) Internal
Indication
Challenge Requires the master to authenticate 0x83 Authentication Group 120, Variation 1 IIN 2.2
Message the previous DNP3 Request Challenge (g120v1) Parameter
OR Authentication Challenge Error
0x84 Unsolicited object
Authentication
Challenge
(periodic challenges)
Response Provides authentication for the 0x81 Response Group 120, Variation 2 None.
Message previous DNP3 Response or DNP3 (g120v2)
Unsolicited Response as requested Authentication Reply object
by the master
Aggressive Provides authentication for the Whatever function code Group 120, Variation 3 As
Mode Request current DNP3 Response or DNP3 is in the DNP3 (g120v3) appropriate
Message Unsolicited Response Response or Unsolicited Authentication Challenge for the
Response object current
DNP3
This object is added to end Response
of the DNP3 Response or
Unsolicited Response
Key Status Reports the current status of the 0x81 Response Group 120, Variation 5 None.
message Session Keys used by the outstation. (g120v5)
Session Key Status object
Error Message Indicates the authentication provided 0x81 Response Group 120, Variation 7 IIN 2.2
in the previous DNP3 Request was (g120v7) Parameter
incorrect or that a Key Change or Authentication Error object Error
Certificate Change request failed.
Inclusion of this object in
the DNP3 Response is
optional. The outstation
may simply respond with
IIN2.2

The function codes specific to the authentication mechanism are defined in the following sections:

3.1.2.1 Function Code 131 (0x83) Authentication Challenge

The outstation uses this function code to issue an authentication challenge to the master. In other words, it requests
that the master authenticate the most recent DNP3 request transmitted by the master.
The DNP3 response message contains a valid Authentication Challenge object, and the following DNP3 request
contains an Authentication Reply object. Rules are applied as in section 3.2 with the DNP3 outstation acting as the
Challenger.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 24
3.1.2.2 Function Code 132 (0x84) Unsolicited Authentication Challenge
The outstation uses this function code to issue a periodic authentication challenge to the master. Use of this function
code follows the usual rules for unsolicited responses.
The DNP3 response message contains a valid Authentication Challenge object, and the following DNP3 request
contains an Authentication Reply object. Rules are applied as in section 3.2 with the DNP3 outstation acting as the
Challenger.
By default, a periodically generated Authentication Challenge object shall be considered to be Class 1 unless
configured otherwise. If unsolicited responses are disabled, the outstation shall queue the Authentication Challenge
object as an event object in the next event poll response.

3.1.3 DNP3 Message Examples

Figure 11 illustrates several of the messages described in the preceding sections as part of a typical
initialization sequence, immediately following initialization of the session keys by the master. The
outstation generates an unsolicited response to notify the master that it has restarted. The master
authenticates this message before supplying a confirmation. The confirmation is not authenticated, but the
outstation requires authentication of the Write operation.
Master Outstation

0x81Unsolicited Response
(no data – RESTART IIN set)

0x21 Authentication Request

g120v1 Authentication Challenge object

0x81 Response
g120v2 Authentication Reply Object

Authenticate
0x00 Confirm
Process
0x02 Write Confirm
g80v1 Internal Indication (clear RESTART)

0x82 Authentication Challenge

g120v1 Authentication Challenge object

0x22 Authentication Reply

g120v2 Authentication Reply Object

Authenticate

Clear
RESTART IIN

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 25
 Figure 11 – Example DNP3 Initialization Sequence
Figure 12 illustrates how a master and outstation would perform a Direct Operate sequence using Challenge-
Response.

Figure 12 – Example DNP3 Direct Operate sequence

Figure 13 illustrates how a master an outstation would perform a Select-Operate sequence using
Aggressive Mode.

Master Outstation
0x03 Select
g12v1 Control Relay Output Block
g120v3 Aggressive Mode Request

Authenticate
0x81 Response
g12v1 Control Relay Output Block
Process
Select

0x04 Operate
g12v1 Control Relay Output Block
g120v3 Aggressive Mode Request

0x81 Response Authenticate

g12v1 Control Relay Output Block
Operate

Figure 13 - Example of DNP3 Select-Operate sequence in Aggressive Mode

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 26
Figure 14 illustrates how a poll-response sequence could be authenticated in Aggressive Mode. The poll
is not considered critical by the outstation, but the confirmation is. Since Responses and Confirms are
optionally critical functions, it is up to the master to require that the Analog Change Events are critical,
and up to the outstation to require that Confirms are critical.

Figure 14 – Example DNP3 Authentication of Polling Data

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 27
3.2 Formal Procedures
This section formally describes the procedures used by devices implementing this authentication mechanism as a
part of each protocol. If this section differs from section 2, this section shall be considered definitive.
The state machines in this section describe the protocol in terms of IEC 62351-5 “messages”. Refer to section 3.1 for
a description of how each of these messages are implemented using DNP3 function codes and objects, in each
direction.

3.2.1 Challenger procedures

3.2.1.1 Challenger Role

A device, either master or outstation, that requires authentication from the other device in order to communicate,
shall be called a Challenger. Challengers shall issue Challenge messages upon Initialization, periodically, and in
response to Critical ASDUs, according to the state machine described in Table 5.
Challengers shall never intentionally retransmit the same Challenge message. Any time a Challenge is issued, it
shall be created using new Challenge Data and a new Challenge Sequence Number.
Note that in order to reach either of the two states described in Table 5, the Challenger must have established a set of
Session Keys using either the Master state machine in Table 6 or the Outstation state machine in Table 7.

3.2.1.2 Critical Functions

Each Challenger shall distinguish between Critical ASDUs and Non-Critical ASDUs. A Critical ASDU shall be a
message implementing a function that the Challenger requires to be authenticated. IEC 62351-5 states the following
minimum requirements:
• Outstations shall consider all output operations (controls, setpoint adjustments, parameter settings, etc.) to
be critical.
• The first ASDU received by any device after it has restarted shall be considered to be a Critical ASDU by
the receiving device.
• Challengers may optionally consider additional functions beyond this minimum subset to be critical.
The following rules are used to identify the DNP3 operations that shall be considered critical, requiring
authentication.
1. Any application layer DNP3 Requests identified with a “MANDATORY” in the “Critical” column of
Table 4 shall be considered critical operations. DNP3 outstations complying with this authentication
mechanism shall require masters to authenticate all DNP3 Request fragments that contain these function
codes.
2. DNP3 outstations may optionally require authentication of any other Request fragments.
3. As described in IEC 62351-5, the first DNP3 Request sent by a DNP3 master and the first DNP3 Response
or Unsolicited Response sent by a DNP3 outstation, regardless of function code, shall also be considered
critical, requiring authentication.
4. Other than the first one transmitted, there are no other DNP3 Responses that are mandatory for a DNP3
master to designate as critical operations. DNP3 masters may optionally require authentication of any
DNP3 Response, but are not required to do so for compliance.
5. If a DNP3 device claims compliance with this authentication mechanism, information identifying those
function-codes and objects the device considers critical, requiring authentication, shall accompany the
Device Profile Document for the device.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 28
 Table 4 – DNP3 Critical Request Function Codes
Function Code
Description Critical
Decimal Hex
0 0x00 Confirm optional
1 0x01 Read optional
2 0x02 Write MANDATORY
3 0x03 Select MANDATORY
4 0x04 Operate MANDATORY
5 0x05 Direct Operate MANDATORY
6 0x06 Direct Operate – No Acknowledgement MANDATORY
7 0x07 Immediate Freeze optional
8 0x08 Immediate Freeze – No Acknowledgement optional
9 0x09 Freeze-and-Clear optional
10 0x0A Freeze-and-Clear – No Acknowledgement optional
11 0x0B Freeze-at-Time optional
12 0x0C Freeze-at-Time – No Acknowledgement optional
13 0x0D Cold Restart MANDATORY
14 0x0E Warm Restart MANDATORY
15 0x0F Initialize Data (obsolete) optional
16 0x10 Initialize Application MANDATORY
17 0x11 Start Application MANDATORY
18 0x12 Stop Application MANDATORY
19 0x13 Save Configuration (deprecated) optional
20 0x14 Enable Unsolicited Responses MANDATORY
21 0x15 Disable Unsolicited Responses MANDATORY
22 0x16 Assign Class optional
23 0x17 Delay Measurement optional
24 0x18 Record Current Time MANDATORY
25 0x19 Open File optional
26 0x1A Close File optional
27 0x1B Delete File optional
28 0x1C Get File Information optional
29 0x1D Authenticate File MANDATORY
30 0x1E Abort File optional
31 0x1F Activate Configuration MANDATORY
32 0x20 Authentication Request (new) Not applicable
33 0x21 Authentication Reply (new) Not applicable
34 0x22 Authentication Error – No Ack (new) Not applicable
129 0x81 Response optional
130 0x82 Unsolicited Response optional
131 0x83 Authentication Challenge (new) Not applicable

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 29
 Function Code
Description Critical
Decimal Hex
132 0x84 Unsolicited Authentication Challenge (new) Not applicable

3.2.1.3 Authentication Procedures

If the Challenger is in any of the states Wait for Key Status, Wait for Key Change, or Wait for Key Change
Confirmation, when it receives a Response message, it shall consider the Response message to be an Rx Invalid
Response event because the Session Keys are not valid. Similarly, if the Challenger receives an Aggressive Mode
Request in any of these states, the Challenger shall consider it to be an Rx Invalid Aggressive Mode Request event.
Upon receiving a Response message, the Challenger shall calculate the HMAC Value from the information it
transmitted in the Challenge message, as described in the definition of the Authentication Challenge object.
If the HMAC Value from the Response matches the calculated HMAC Value, and the Challenge Sequence Numbers
from the Challenge and Response messages also match, the Challenger shall consider the Response message to be a
Rx Valid Response event.
Otherwise, the Challenger shall consider the Response message to be an Rx Invalid Response event.
Upon receiving an ASDU containing an Aggressive Mode Request, the Challenger shall calculate the HMAC Value
from the information in the ASDU as described in the definition of the Authentication Aggressive Mode Request
object. If the HMAC Value in the Aggressive Mode Request matches the calculated HMAC Value and the
Challenge Sequence Number in the Aggressive Mode Request is correct as described in the definition of the
Authentication Aggressive Mode Request object, the Challenger shall consider the ASDU to be a Rx Valid
Aggressive Mode Request event.
Otherwise, the Challenger shall consider the Aggressive Mode Request message to be an Rx Invalid Aggressive
Mode Request event.
In particular, the Challenger shall consider any Aggressive Mode Request to be an Rx Invalid Aggressive Mode
Request event if the Challenger has not previously received at least one Rx Valid Response event from the
Responder. This rule follows from the definition of the Aggressive Mode Request, because the Challenge Sequence
Number in an Aggressive Mode Request is derived from the Challenge Sequence Number found in the Challenge
most recently received by the Responder.

3.2.1.4 Challenge Timer

The Challenger shall periodically issue Challenge messages that are not responses to Critical ASDUs. The
Challenger shall control the interval between Challenge messages using a Challenge Timer. The Challenger shall
start each Challenge Timer by adding together two configurable values:
• Periodic timeout (refer to section 4.1.4.1)
• Random timeout factor (refer to section 4.1.4.2)

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 30
 3.2.1.5 Challenger State Machine
Challengers (either master or outstation) shall implement the state machine described in Table 5.
Table 5 – Challenger State Machine
State

Security Idle Wait for Response

Event Event Description
The device is executing the standard DNP3 protocol. The device is waiting for the other device to authenticate itself.
Action Next State Action Next State
Rx Non-Critical The other device transmits an ASDU that Execute the Non-Critical ASDU and Security Idle Discard the ASDU. Security Idle
ASDU does not require authentication. transmit any appropriate response Increment the Error count.
required by the standard protocol.
If the Maximum Error Count has not been
exceeded, transmit an Error Message with
reason <2> Unexpected Response.
Rx Critical The other device transmits an ASDU that Increment the Challenge Sequence Wait for Discard the Critical ASDU. If the Maximum Wait for
ASDU requires authentication. Number (CSQ) Response Error Count has not been exceeded, transmit Response
NOTE: The first ASDU after initialization, Create and transmit a Challenge message an Error Message with reason <2> Unexpected
e.g. General Interrogation, shall be calculated from the Critical ASDU. Response.
considered a Critical ASDU in all protocols. Start the Response Timer.
Queue the Critical ASDU for execution
later.
Challenge Increment the Challenge Sequence Wait for Restart the Challenge Timer. Wait for
Timeout Number (CSQ) Response Response
A Challenge Timer has expired. Refer to Create and transmit a periodic Challenge
section 3.2.1.4. message.
Start the Response Timer.
Restart the Challenge Timer.
Rx Valid The other device transmits a Response Discard the message. Security Idle Perform the operations specified in the queued Security Idle
Response message that correctly authenticates the Critical ASDU, if any, and transmit any
other device based on a previous appropriate response required by the standard
Challenge. protocol.
Cancel the Response Timer.
Reset the Error Count to zero.
Rx Invalid The other device transmits a Response Discard the message. Security Idle Increment the Error count. Security Idle
Response message that does not correctly If the Maximum Error Count has not been
authenticate the other device. exceeded, transmit an Error Message with
reason <1> Authentication Failed. Cancel the
Response Timer.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 31
 State

Security Idle Wait for Response

Event Event Description
The device is executing the standard DNP3 protocol. The device is waiting for the other device to authenticate itself.
Action Next State Action Next State
If the Maximum Error Count has been
exceeded, behave according to the “Max
Invalid Responses” event below.
Response The Response Timer started when entering Should not occur. Security Idle Increment the Error count. Security Idle
Timeout Wait for Response state has expired. This If the Maximum Error Count has not been
may be the standard response timer for the exceeded, transmit an Error Message with
protocol. reason <3> No Response.
Refer to clause 4.1.4.3 for details regarding If the Maximum Error Count has been
the Response Timer. exceeded, behave according to the “Max
Invalid Responses” event below.
Max Invalid • The Maximum Error Count has MASTER: Wait for Key MASTER: Wait for Key
Responses been exceeded in Wait for Transmit a Key Status Request Message. Status Transmit a Key Status Request Message. Status
Or Response state.
Start the Response Timer. Start the Response Timer.
Link Failure • The data link layer of the protocol
Detected has detected a link failure for OUTSTATION: Wait for Key OUTSTATION: Wait for Key
some other reason. Set the current Key Status to LINK FAIL Change Set the current Key Status to AUTH FAIL Change
Refer to section 4.1.4.3 for details regarding
the Response Timer.
Error Message The other device has transmitted an Error Log the Error message, noting that the Security Idle Log the error message. If the Error Code is <5> Security Idle
Message. message was unexpected. HMAC algorithm Not Permitted, use a different
HMAC algorithm to send the next Challenge.
Do not send another Challenge immediately,
but wait for an appropriate event to cause the
Challenge.
Backward The other device transmits an ASDU No Challenge was issued, so perform Security Idle Do not respond. Security Idle
Compatibility specifically indicating that it does not according to the standard protocol. Set the Error Count to the Maximum Error
Error recognize the Challenge message as valid, Count plus one.
e.g. a Cause of Transmission of
Unrecognized ASDU Type. Continue with the standard protocol until the
next event requiring a Challenge.
Key Change For MASTER only. Either the Key Change Transmit a Key Change Request Wait for Key Queue the event and process it after returning Wait for
Timeout timer has expired, or The Key Change Message. Change to Security Idle state. Response
Count has been exceeded. Refer to section Start the Response Timer. Confirmation
4.1.4.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 32
 State

Security Idle Wait for Response

Event Event Description
The device is executing the standard DNP3 protocol. The device is waiting for the other device to authenticate itself.
Action Next State Action Next State
Expected Key For OUTSTATION only. Set Key Status = NOT INIT Wait for Key Set Key Status = NOT INIT Wait for Key
Change The controlled station has not received a Invalidate current session keys. Change Invalidate current session keys. Change
Timeout valid Key Change message within twice the
interval or ASDU count configured at the
controlling station. Refer to clause 4.1.4.
Rx Key Status For OUTSTATION only. Transmit a Key Status message with Key Security Idle Transmit a Key Status message with Key Wait for
Request The master has transmitted a Key Status Status = OK. Status = OK. Response
Request message.
Rx Valid The other device transmits an ASDU IF this device supports Aggressive Mode: Security Idle Increment the Error Count. If the Maximum Security Idle
Aggressive containing an Aggressive Mode Request Perform the operations specified in the Error Count has not been exceeded, transmit
Mode Request message that correctly authenticates the ASDU containing the Aggressive Mode an Error Message with reason <2> Unexpected
other device. Request and transmit any appropriate Response.
response required by the standard
protocol.
IF this device does not support Aggressive Security Idle
Mode, discard the request and Increment
the Error Count.
If the Maximum Error Count has not been
exceeded, transmit an Error Message with
reason <4> Aggressive Mode Not
Supported.
Rx Invalid The other device transmits an ASDU IF this device supports Aggressive Mode: Security Idle Increment the Error Count. If the Maximum Security Idle
Aggressive containing an Aggressive Mode Request Increment the Error Count. If the Error Count has not been exceeded, transmit
Mode Request that does not correctly authenticate the Maximum Error Count has not been an Error Message with reason <2> Unexpected
other device. exceeded, transmit an Error Message with Response.
Note that all Aggressive Mode Requests reason <1> Authentication Failed.
are invalid until a
IF this device does not support Aggressive Security Idle
Mode, discard the request and Increment
the Error Count.
If the Maximum Error Count has not been
exceeded, transmit an Error Message with
reason <4> Aggressive Mode Not
Supported.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 33
3.2.1.6 Error Messages
As described more formally in Table 5, devices may initially respond to error conditions by transmitting Error
messages. To help protect against denial-of-service attacks, a device shall stop transmitting Error messages after it
has counted a number of errors that exceeds a preset Maximum Error Count, described in 4.1.4.8. Devices may also
choose to not send error messages at any time, regardless of error count.

3.2.2 Responder procedures

3.2.2.1 Responder Role

A device, either master or outstation, that supplies authentication data shall be called a Responder. Each Responder
shall follow the procedures described in this section.

3.2.2.2 Responding to Challenges

A Responder shall respond to a Challenge message with a correctly-formed Response message within an acceptable
Response Timeout defined per system as described in 4.1.4.3.
A Responder shall not proceed with further communications until it has successfully responded to the Challenge
message. This rule includes not responding to any subsequent Challenge messages until the current Challenge is
completed.

3.2.2.3 Aggressive Mode

Aggressive mode, in which a device supplies authentication information in the same ASDU as the data it is
authenticating, shall be optional.
If any device implements Aggressive Mode, it shall also provide a mode of operation in which Aggressive Mode is
disabled.
A Responder that uses Aggressive Mode shall place a correctly-formed Aggressive Mode Request within the ASDU
being authenticated. The location and the formatting of the Aggressive Mode Request within the ASDU shall be
specific to the protocol and described in the specifications of the affected protocol.
A Responder shall not transmit an Aggressive Mode Request until it has successfully responded to at least one
Challenge message.

3.2.3 Master Procedures

3.2.3.1 Master Role

In addition to acting as a Challenger and a Responder, Masters shall follow the procedures described in this section
in order to initialize and change keys at the outstation.

3.2.3.2 Changing Session Keys

There shall be two Session Keys, one used for authenticating data in the Monitoring Direction, and one for
authenticating data transmitted in the Control Direction, as described in Table 1. The outstation and masters shall
maintain a unique set of Session Keys for each user of the outstation.
Each master shall initialize the Session Keys upon establishing communications, and periodically change the
Session Keys as described in Table 6. The change interval shall be set using a configurable parameter as discussed
in 4.1.4.4.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 34
The master shall use a symmetric Update Key to encrypt the Session Key and transmit it to the outstation in a Key
Change message. There shall be a separate Update Key for each user of the outstation.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 35
3.2.3.3 Master State Machine
The master shall execute the state machine in Table 6.
Table 6 – Master State Machine
State

Wait for Key Status Wait for Key Change Confirmation

Event Event Description The master is waiting for the outstation to send confirmation that
The master is waiting for the outstation to send
the Key Change has been accepted, by transmitting a Key Status
any Key Status message.
message with the Key Status = <1> OK
Action Next State Action Next State
Init The master has initialized Transmit a Key Status Wait for Key Status Not possible. Not possible.
Request message. Start
the Response Timer.

Rx Key Status <> OK The outstation has transmitted a Key Status Transmit a Key Change Wait for Key Transmit a Key Status Request message. Wait for Key
message with the Key Status set to a value message. Start the Change Start the Response Timer. Status.
other than <1> OK. Response Timer. Confirmation
Rx Key Status = OK The outstation has transmitted a Key Status Transmit a Key Change Wait for Key Set internal flag indicating that the next Security Idle
message with the Key Status set to <1> message. Start the Change ASDU to be received will be considered
OK. Response Timer. Confirmation Critical.
Start the Key Change timer and reset the
Key Change counter.
Key Change Timeout Either the Key Change Timer has expired Transmit a Key Status Wait for Key Status Transmit a Key Status Request message. Wait for Key Status
OR on the master, or the number of transmitted Request message. Start Start the Response Timer.
or received protocol messages has the Response Timer.
Response Timeout exceeded the Message Count Threshold, or
the Response Timer has expired.
Rx Challenge message The master has transmitted a Challenge If the Maximum Error Wait for Key Status If the Maximum Error Count has not been Wait for Key
message or Aggressive Mode Request Count has not been exceeded, transmit an Error Message with Change
message even though the Session Keys exceeded, transmit an reason <1> Authentication failed Confirmation
are not yet valid. Error Message with reason
<1> Authentication Failed

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 36
3.2.4 Outstation procedures

3.2.4.1 Outstation Role

In addition to acting as a Challenger and a Responder, each outstation shall follow the procedures described in this
section, permitting the Master to initialize and change Session Keys.

3.2.4.2 Key Status

The outstation shall maintain an internal variable having the possible values of Key Status described in the definition
of the Authentication Key Status object, and return this value in response to each Key Status Request Message.

3.2.4.3 Authenticating Session Key Changes

Upon receiving a Key Change message, the outstation shall unwrap the Key Wrap Data in the Key Change message
using the current Update Key.
If the Key Status information in the Key Wrap Data matches the last Key Status information transmitted by the
outstation, the outstation shall consider the Key Change message authentic and valid.
If any of the unwrapped Key Status information does not match the last Key Status information transmitted by the
outstation, the outstation shall consider the Key Change message invalid.

3.2.4.4 Changing Session Keys

An outstation shall respond to a Key Change message within an acceptable Response Timeout defined per system as
described in section 4.1.4.3.
An outstation shall be configured with a timer such that it shall invalidate a set of session keys if it has not received
a Key Change message within twice the interval configured at the master, as described in 4.1.4.6

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 37
3.2.4.5 Outstation State Machine
The outstation shall execute the state machine described in Table 7.
Table 7 – Outstation State Machine

Event Event Description State

Wait for Key Change
The master is waiting for the outstation to send a Key Change
message.
Init The outstation has initialized Set Key Status = NOT INIT Wait for Key Change
Rx Key Status The master has transmitted a Transmit Key Status message with Wait for Key Change
Request Key Status request message. most recently set status.
Rx Valid Key The master has transmitted a Store new keys. Security Idle
Change correctly authenticated Key Set Key Status = OK.
Change message.
Set flag indicating that next ASDU
will be considered critical.
Rx Invalid Key The master has transmitted an Set Key Status = AUTH FAIL. Wait for Key Change
Change improperly authenticated Key Transmit Key Status message.
Change message.
Rx Challenge The master has transmitted a Increment the error count. Wait for Key Change
message Challenge message or If the Maximum Error Count has
Aggressive Mode Request not been exceeded, transmit an
message even though the Error Message with reason <1>
Session Keys are not yet valid. Authentication Failed.

Expected The controlled station has not Set Key Status = NOT INIT Wait for Key Change
Session Key received a valid Key Change Invalidate current session keys.
Timeout message within twice the
interval or count configured at
the controlling station.

3.2.5 DNP3 Sequence Numbering

Each DNP3 authentication Challenge, Response or Error message shall have the same DNP3 application
sequence number as the critical DNP3 fragment that was challenged.
Figure 15 illustrates how this rule would be applied for a Select/Operate control sequence using challenge
and response. DNP3 application sequence numbers are shown in parentheses. Figure 16 illustrates that
when Aggressive Mode is used, the sequence numbering is identical to normal non-authenticated DNP3.
When a device initiates a periodic challenge, it shall increment the DNP3 application sequence number
according to the normal rules of DNP3. Unless it is challenging a critical DNP3 function, the device shall
not interrupt a DNP3 exchange, even if the Challenge Timer expires in the middle of a non-critical DNP3
exchange. Figure 17 illustrates this rule.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 38
 Master Outstation

(7) Poll (non-critical)

(7) Poll response

(8) Select

(8) Authentication Challenge

(8) Authentication Reply

Authenticate

(8) Select response

Process
Select

(9) Operate

(9) Authentication Challenge

(9) Authentication Reply

Authenticate

(9) Operate response

Operate

Figure 15 – Example of DNP3 Sequence Numbering for Select/Operate Authentication

Master Outstation

(8) Select (Aggressive Mode)

Authenticate

(8) Select response

Process
Select

(9) Operate (Aggressive Mode)

Authenticate

(9) Operate response

Operate

Figure 16 - DNP3 Sequence Numbering for Select/Operate Authentication in Aggressive Mode

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 39
 Outstation
(5) Event poll Challenge
Timer
Expires
(5) Event Poll response

(6) Periodic Challenge

(6) Authentication Reply

Authenticate

Master Outstation
Challenge (5) Event poll
Timer
Expires
(5) Event Poll response

(6) Periodic Challenge

(6) Authentication Reply

Authenticate

Figure 17 Example of DNP3 Sequence Numbering for Periodic Challenges

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 40
4 INTEROPERABILITY REQUIREMENTS
This section describes which capabilities shall be considered to fall into the following categories:
• Mandatory to ensure interoperability between devices
• Optional but required to be tested if implemented
• Recommended practices

4.1 Minimum Requirements

This section describes the mandatory minimum capabilities required for a device to comply with this specification.

4.1.1 HMAC Algorithms

Each device shall implement the HMAC algorithms listed in this section.

4.1.1.1 HMAC-SHA1
Each device shall permit the use of HMAC-SHA1, as described in the references in section 1.2 to calculate the
HMAC Value. The HMAC Value shall be the 160 bits (20 octets) output of the HMAC algorithm, truncated to
either the leftmost 4 octets or the leftmost 8 octets. If this specification is used over TCP/IP, the truncated value shall
be 8 octets. If it is used over serial links, the truncated value shall be 4 octets.
This shall be the default HMAC algorithm.

4.1.2 Key Wrap Algorithms

Each device shall implement key wrap algorithms as described in this section.

4.1.2.1 AES-128 Key Wrap

Each device shall permit the use of the Advanced Encryption Standard Key Wrap mechanism, as described in the
references in section 1.2, to encrypt and decrypt Session Keys. The Key Encryption Key (KEK) referred to in the
Key Wrap specification shall be the Update Key. The default initialization vector shall be used.

4.1.3 Fixed values

Each device shall fix the following parameters to comply with this specification:

4.1.3.1 Minimum session key size

The minimum size of the Session Keys used to calculate the HMAC Value shall be 128 bits.

4.1.3.2 Minimum update key size

The minimum size of the Update Key used to encrypt and decrypt Session Keys shall be 128 bits.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 41
4.1.4 Configurable values

Each device shall permit changes to the parameters described in this section. Changes to these parameters shall be
permanently retained over restarts of the device.

4.1.4.1 Periodic challenge interval

The periodic challenge interval shall be settable in seconds. The default value shall be 20 minutes. The maximum
value shall be no greater than 1 hour.

4.1.4.2 Maximum random challenge interval

The maximum random challenge interval to be added to the periodic challenge interval shall be settable in seconds
with a maximum no greater than one-half the periodic challenge interval, and defaulted to that value. The algorithm
used to calculate the random challenge interval shall be a local matter provided the algorithm can generate a 0 value
and the maximum random challenge interval value.

4.1.4.3 Response timeout

The response timeout used by devices to detect communication failures shall be settable in hundreds of milliseconds.
The default value shall be 2 seconds. The maximum value shall be no less than 120 seconds.

4.1.4.4 Session Key change interval

The session key change timeout used by the master to determine when to change session keys shall be settable in
seconds up to 2 hours. The default value shall be 15 minutes.
IMPORTANT: Implementors should not increase the Session Key change interval beyond 30 minutes unless they
also increase the size of the HMAC Value. FIPS-198 requires HMAC output to be truncated to no less than half its
standard size, “unless an application or protocol makes numerous trials impractical”. In the case of this
authentication mechanism, the requirement for frequent changes of Session Keys fulfils this criterion and makes it
possible to use shorter HMAC Values.

4.1.4.5 Session Key change count

The master shall also change session keys whenever a configured number of ASDUs has been transmitted in either
direction since the last key change. The value shall be settable in increments of one. The default value shall be 1000.
The maximum value shall be no less than 10 000.

4.1.4.6 Expected Session Key change interval and count

The outstation shall maintain a timer and a count between successive Key Change messages in the same
manner as the master. This timer and count shall be configured such that the outstation shall invalidate the
current set of Session Keys if they have not been changed within twice the interval or count configured at
the master.

4.1.4.7 Use of aggressive mode

Aggressive Mode is considered optional by IEC 62351-5. However, it is not optional for DNP3. All DNP3
implementations claiming conformance to this specification shall implement it. They shall also permit it to be
configured as disabled.

4.1.4.8 Maximum error count

Configuring Maximum Error Count is considered optional by IEC 62351-5. However, it is not optional for DNP3.
The maximum error count shall be configurable up to a maximum of 10 errors or down to 0. The default shall be 2.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 42
4.2 Options
This section describes capabilities that are not required for compliance with this specification, but may be
implemented as options. If a device implements these capabilities, they shall be verified for compliance. If a device
implements any capabilities not listed in this section, the device must provide a mode in which these capabilities are
disabled.

4.2.1 HMAC algorithms

Each device may implement additional HMAC algorithms in addition to those listed as mandatory. If the device
receives an Error message with the Error Code <5> HMAC algorithm Not Permitted, it shall change to use a
mandatory HMAC algorithm in its next Challenge. A device may be configured to reject particular mandatory
HMAC algorithms, but it must also support configuration to support all the mandatory HMAC algorithms.

4.2.1.1 HMAC-SHA256
It is recommended that devices permit the use of HMAC-SHA256, as described in the references in section 1.2, to
calculate the HMAC Value. The HMAC Value shall be the 256 bits (32 octets) output of the HMAC algorithm,
truncated to either the leftmost 8 octets or the leftmost 16 octets. When this authentication mechanism is used over
TCP/IP, the truncated value shall be 16 octets. On serial implementations, it shall be 8 octets.

4.2.2 Key Wrap algorithms

Each device may implement additional Key Wrap algorithms in addition to those listed as mandatory. If the device
receives an Error message with the Error Code <6> Encryption Algorithm Not Permitted, it shall change to use a
mandatory Encryption Algorithm in its next Challenge. A device may be configured to reject particular mandatory
encryption algorithms, but it must also support configuration to support all the mandatory encryption algorithms.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 43
5 SPECIAL APPLICATIONS
This section defines how this specification shall be applied in a few specific situations.

5.1 Use with the Internet Protocol Suite

DNP3 implementations over TCP/IP shall use both this application layer mechanism and the standard for use of
Transport Layer Security (TLS) as specified by IEC 62351 Part 3. A subsequent Technical Bulletin will be issued to
describe how DNP3 devices shall implement that standard with regard to specific algorithms, port numbers,
timeouts etc.
DNP3 implementations over UDP/IP shall use this application layer authentication mechanism by itself. Some
implementations may choose to use other security measures (such as IPSec) along with this specification, but they
are out of the scope of this specification.
When operating over IP, it may be possible to change and distribute Update Keys by making use of other IP-based
security protocols. The DNP Users Group intends to develop specifications for this purpose. However, such
mechanisms are also outside the scope of this specification as of the date of its publication.

5.2 Use with Redundant Channels

When used with redundant channels the link shall not be considered to have failed and the Session Keys invalidated
until all channels have been tried.

5.3 Use with External Link Encryptors

This authentication mechanism may be used along with external link encryptors to provide protection against the
threat of eavesdropping.
It is recommended for simplicity that a common set of keys be used for both authentication and encryption.
However, the definition of such rules is out of scope of this specification.

5.4 Use with Data Concentrators

This section describes special requirements when the authentication mechanism is used by a data
concentrator.

5.4.1 Definition of a Data Concentrator

Figure 18 illustrates an example of a typical system making use of a DNP3 data concentrator. A data
concentrator does not pass DNP3 messages through itself intact, as a router or bridge does. Instead, a data
concentrator terminates multiple connections of DNP3 or other protocols and stores the data from each
direction in an internal run-time database. This permits the concentrator to filter the data, process it within
internal software applications, or convert it into other protocols.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 44
Data may pass through a data concentrator either “upstream”, toward DNP3 masters, or “downstream”,
toward DNP3 outstations, also known as Intelligent Electronic Devices (IEDs). DNP3 point numbers and
DNP3 addresses used on any given connection may be the same or different than those used on any other
connection. The data concentrator maps point numbers used on one connection to the corresponding point
numbers on the other connections through the run-time database.

Figure 18 – Example of User Number Assignments in a Data Concentrator

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 45
5.4.2 Authentication Procedures for Data Concentrators

When a data concentrator makes use of DNP3 secure authentication, it shall follow the general rule that
whenever it can distinguish the particular user who initiated an operation, it shall identify that user to
downstream outstations. This rule is intended to deter repudiation by permitting concentrators or
outstations to log which user initiated critical DNP3 operations. The following rules shall apply as
clarifications of that rule:
1. The data concentrator shall identify each user having a DNP3 User Number (USR) on the
upstream side with a separate DNP3 User Number on the downstream side. For instance, in
Figure 18, Alice and Bob have User Numbers on both the upstream DNP3 link used by process
“A” and the downstream DNP3 links used by process “C”.
2. If an upstream protocol cannot distinguish individual users, the data concentrator shall identify
each upstream protocol connection with a separate User Number on the downstream side. For
instance, process “B” cannot distinguish whether protocol commands are initiated by Charlie or
Donald. Therefore the data concentrator uses a single User Number on the downstream DNP3
link used by process “C” to represent all users on Master 2.
3. The data concentrator shall identify local users and applications with separate User Numbers on
the downstream side. For instance, local application “E” has its own User Number on the
downstream DNP3 link. If the data concentrator had a local user interface capable of
distinguishing different local users, it would identify each of these local users with a different
User Number on the downstream DNP3 link.
4. User Numbers shall be unique within an outstation. User Numbers need not be sequential, but
each User Number must uniquely identify a user of an outstation, and a unique Update Key and a
set of Session Keys to be associated with that user. Note, however, that because the maximum
User Number is 255 and 0 is reserved, an outstation may only have 255 users that access it
through a given data concentrator. If more than 255 users of one outstation are required, use of
multiple DNP3 addresses and logical devices by the outstation is recommended. In addition, the
data concentrator is an outstation with respect to an upstream master, and it has the same 255-
user limitation with the master.
5. The User Number used to identify a user on any given link may be different than that used on any
other link. For instance, Alice’s User Number on the upstream DNP3 link is 7, but her User
Number on the link between the data concentrator and Outstation 3 is 22. She may have a
different User Number on the link with Outstation 1.
6. If no points are mapped between an upstream or local user and a downstream outstation, the
data concentrator need not map User Numbers either. The Figure 18 illustrates that all the users
identified in the diagram have the potential to make use of Outstation 3. However, not all users
may have the potential to access Outstation 1, for instance, and therefore Outstation 1 may not
have any User Numbers to distinguish them.
7. When upstream or local users initiate critical DNP3 requests that are passed through to
downstream outstations, the data concentrator shall correctly identify the user making the
request. If Alice initiates a binary output operation on a point that is mapped to Outstation 3, the
data concentrator first authenticates the request with Master 1 using Alice’s upstream User
Number (7). Next, the data concentrator issues the corresponding binary output operation to
Outstation 3, and it uses Alice’s downstream User Number (22) when Oustation 3 requests the
data concentrator to authenticate that request. Similarly, if the local automation process initiates a
Freeze and Clear on several counters and Outstation 3 considers it a critical operation, the data
concentrator shall authenticate the request with Outstation 3 specifying User Number 112.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 46
 8. When the data concentrator spontaneously or periodically initiates a critical DNP3 request on
behalf of multiple users, it shall identify itself as the user. For instance, process “C” periodically
initiates regular Class Data polls to gather data that will later be distributed to Alice, Bob and
Charlie, even though none of those users specifically initiated the poll request. It is not
mandatory that Class Data polls be considered critical. However, if Outstation 3 chose to
challenge a Class Data poll from the data concentrator, the data concentrator would authenticate
the poll identifying itself (User Number 75) as the initiating user.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 47
6 COMPLIANCE WITH IEC 62351-5
IEC 62351 Part 5 states that protocols claiming compliance to it must include certain items in their
specification. This section describes where in this specification those items are located.

6.1 Selected options

Application layer authentication security in DNP3 is provided through an implementation of the IEC
62351-5 standard. IEC 62351-5 states:
• The protocol specification shall identify which of the options identified in clause 8.3 are mandatory for the
protocol (if any).
• The protocol specification shall identify any additional security algorithms, fixed parameters, configurable
parameters or features supported by the protocol beyond the mandatory set specified in clause 8.2.
The Device Profile Document for each DNP3 device supporting IEC 62351-5 authentication shall identify this
capability. Authentication is considered a subset of either master or outstation functionality to which a device may
claim compliance, separate from any other subset.
All DNP3 devices shall support IEC 62351-5 Aggressive Mode authentication in order to claim compliance to IEC
62351-5 and DNP3. As noted in the specification, devices must also permit Aggressive Mode to be disabled via
configuration.
All DNP3 devices shall permit the Error Count to be configurable.
The Device Profile Document for DNP3 devices claiming compliance with IEC 62351-5 shall also include the
following information:
• A list of any and all hashing algorithms supported by the device in addition to the mandatory algorithms
identified in IEC 62351-5.

• A list of any and all encryption algorithms supported by the device addition to the mandatory algorithms
identified in IEC 62351-5.

6.2 Operations Considered Critical

IEC 62351-5 states:
• The protocol specification shall identify which protocol operations (e.g. function codes, ASDU types,
control commands, setting changes) shall be considered Critical, requiring authentication through this
mechanism.
• The protocol specification shall specify that certain operations described in clause 3.2.1.2 of this
specification are always Critical.
The mandatory and optional critical operations for DNP3 are specified in section 3.2.1.2.

6.3 Addressing Information

IEC 62351-5 states:

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 48
 • The protocol specification shall identify which addressing information from the lower layers of the protocol
shall be included in the HMAC calculation, as described in clauses 7.2.3.5 and 7.2.4.5, and the order of
their octets in the calculation.
DNP3 does not include any addressing information in the HMAC calculation, as described in the Data Object
Library insert sheets for Group 120.

6.4 Message Format Mapping

IEC 62351-5 states:
• The protocol specification shall describe how each of the messages described in clause 7.2 shall be
implemented using the protocol.
• The message formats described in the protocol specification message formats shall include all information
found in the messages described in this specification.
• In general, the protocol specification shall use the sequence, layout, and naming of information described
in this specification. The only exception to this requirement occurs if an equivalent piece of information
already exists elsewhere in a protocol ASDU (such as a length parameter). Under such conditions the
format and layout described in this specification may be altered. Such a parameter shall not be removed
from the protocol entirely.
• The protocol specification shall not reduce the size or range of any information described in this
specification.
The mapping of message formats is described in section 3.1 and the Data Object Library insert sheets for Group 120.
Notes there describe how the length of challenge data and some other fields is implemented using DNP3 qualifier
codes.

6.5 Reference to Procedures

IEC 62351-5 states:
• The protocol specification shall specify how the procedures described in clause 7.3 shall be implemented
using the protocol.
• If there is a disagreement between the procedures described in the protocol specification and the
procedures described in this specification, this specification shall be deemed to be the correct description.
The DNP3 procedures are described in section 3.2 and are intended to be identical to those described in IEC 62351-
5.

DNP3 Specification, Volume 2, Supplement 1, Secure Authentication DNP3Spec-V2-Sup1-SecureAuthentication-20070203

3 February 2007 Page 49