57/1001/CD

COMMITTEE DRAFT (CD)

Project number

IEC/TC or SC :

TC 57

IEC/TS 62351-8 Ed. 1.0

Title of TC/SC:

Date of circulation

Closing date for comments

2009-05-01

2009-08-07

Power systems management and associated

information exchange
Also of interest to the following committees

Supersedes document

57/914/NP - 57/949/RVN
Functions concerned:

Safety
Secretary:

Dr. Andeas Huber, Germany

EMC

Environment

Quality assurance

THIS DOCUMENT IS STILL UNDER STUDY AND SUBJECT TO

CHANGE . IT SHOULD NOT BE USED FOR REFERENCE PURPOSES .
RECIPIENTS OF THIS DOCUMENT ARE INVITED TO SUBMIT , W ITH
THEIR COMMENTS , NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF W HICH THEY ARE AW ARE AND TO PROVIDE
SUPPORTING DOCUMENTATION .

Title:
Power systems management and associated information exchange - Data and communications
security - Part 8: Role-based access control
(Titre) :

Introductory note

Copyright 2009 International Electrotechnical Commission, IEC. All rights reserved. It is

permitted to download this electronic file, to make a copy and to print out the content for the sole
purpose of preparing National Committee positions. You may not copy or "mirror" the file or
printed version of the document, or any part of it, for any other purpose without permission in
writing from IEC.

FORM CD (IEC)
2002-08-08

62351-8/CD IEC(E)

5771001/CD

CONTENTS
1

Purpose and Scope ..........................................................................................................7

1.1 Purpose...................................................................................................................7
1.2 Scope......................................................................................................................7
1.3 RBAC and the AAA-Framework................................................................................8
1.4 Justification .............................................................................................................9
1.5 Out of Scope ...........................................................................................................9
Normative references...................................................................................................... 10

Terms and definitions ..................................................................................................... 11

Abbreviated terms........................................................................................................... 13

RBAC Process model (informative) ................................................................................. 15

5.1

Privilege management infrastructure ...................................................................... 15

5.1.1 Use of push or pull..................................................................................... 15
5.2 Separation of subjects, roles, and rights................................................................. 16
5.2.1 Subject assignment.................................................................................... 17
5.2.2 Right assignment ....................................................................................... 17
5.2.3 Operation assignment ................................................................................ 18
5.3 General architecture components of the RBAC model (roles, rights, formats,
transport, verification) ............................................................................................ 18
5.4 Management of subject rights ................................................................................ 19
5.5 Criteria for defining roles ....................................................................................... 19
5.5.1 Policies...................................................................................................... 19
5.5.2 Introducing roles reduces complexity.......................................................... 20
5.5.3 Separation of duty does not increase complexity ........................................ 20
Role definitions (normative) ............................................................................................ 21
6.1

Credentials ............................................................................................................ 21
6.1.1 Profiles ...................................................................................................... 21
6.1.2 Mandatory fields in credential..................................................................... 21
6.1.3 Optional fields in credentials ...................................................................... 21
6.1.4 Mandatory profile-specific fields ................................................................. 21
6.1.5 Resolution of timestamp............................................................................. 22
6.1.6 Maximal lifetime of credential ..................................................................... 22
6.1.7 Size of credentials ..................................................................................... 22
6.1.8 Number of issuers...................................................................................... 22
6.2 Role-right assignment ............................................................................................ 22
6.2.1 Number of supported rights ........................................................................ 22
6.2.2 Number of supported roles ......................................................................... 22
6.2.3 Flexibility of role-right mapping................................................................... 22
6.3 Role-Right assignment with respect to power systems............................................ 22
6.3.1 Power utility automation - IEC 61850 .......................................................... 22
6.3.2 CIM IEC 61968 ....................................................................................... 27
6.3.3 AMI............................................................................................................ 27
6.3.4 DA ............................................................................................................. 27
6.3.5 Markets ..................................................................................................... 27
6.4 Role-Right Assignment with respect to other Non-Power System domains
(e.g. industrial process control) .............................................................................. 27
Role formats (normative) ................................................................................................ 28
7.1

Profile A: X.509 ID Certificate with extensions ........................................................ 28

62351-8/CD IEC(E)

57/1001/CD

7.1.1 Field of applications (informative)............................................................... 28

7.2 Profile B: X.509 Attribute Certificate ....................................................................... 29
7.2.1 Field of applications (Informative) .............................................................. 29
7.2.2 Mapping between ID and Attribute Certificate (informative) ......................... 30
7.3 Software Token ..................................................................................................... 30
7.3.1 Hash function ............................................................................................ 31
7.4 Distribution of the credentials................................................................................. 31
7.5 Extension for the credential (informative) ............................................................... 31
Transport profiles (normative) ......................................................................................... 32
8.1

Usage in Ethernet-based protocols ........................................................................ 32

8.1.1 Profile A: X.509 ID Certificate with extensions ............................................ 32
8.1.2 Profile B: X.509 Attribute certificate............................................................ 32
8.1.3 Profile C: Software Token .......................................................................... 32
8.2 Usage in non-Ethernet based protocols .................................................................. 32
End device verification of credentials .............................................................................. 33
9.1
9.2

Items to be verified (normative/optional)................................................................. 33

Revocation lists (optional) ...................................................................................... 33
9.2.1 General ..................................................................................................... 33
9.2.2 Supported Methods .................................................................................... 33
10 Interoprability.................................................................................................................. 34
10.1
10.2
10.3
10.4
10.5

Supported credentials ............................................................................................ 34

List of Supported Profiles....................................................................................... 34
How to ensure backward compatibility (normative) ................................................. 34
How to extend the list of roles and rights ................................................................ 34
How to map this specification to specific authorization mechanisms ....................... 34

Figure 1 Overview RBAC architecture ...................................................................................7

Figure 2 Generic AAA framework according to RFC2903 ......................................................8
Figure 3 Diagram of a RBAC with static and dynamic seraration of duty according to
[4] 16
Figure 4 User, roles, rights and operations ......................................................................... 17
Figure 5 Schematic view of authorization meachnism based on RBAC ................................ 19
Table 1 Pre-defined roles according to IEC 61850 .............................................................. 25
Table 2 List Pre-defined roles and right assignment (IEC 61850 service/rights) ................... 25
Table 3 Attribute certificate structure .................................................................................. 29
Table 4 Mapping between PKI and PMI............................................................................... 30
Table 5 List of profiles ........................................................................................................ 34

62351-8/CD IEC(E)

5771001/CD

INTERNATIONAL ELECTROTECHNICAL COMMISSION

___________
Data and Communication Security
FOREWORD
1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising
all national electrotechnical committees (IEC National Committees). The object of IEC is to promote
international co-operation on all questions concerning standardization in the electrical and electronic fields. To
this end and in addition to other activities, IEC publishes International Standards, Technical Specifications,
Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as IEC
Publication(s)). Their preparation is entrusted to technical committees; any IEC National Committee interested
in the subject dealt with may participate in this preparatory work. International, governmental and nongovernmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely
with the International Organization for Standardization (ISO) in accordance with conditions determined by
agreement between the two organizations.
2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international
consensus of opinion on the relevant subjects since each technical committee has representation from all
interested IEC National Committees.
3) IEC Publications have the form of recommendations for international use and are accepted by IEC National
Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC
Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any
misinterpretation by any end user.
4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications
transparently to the maximum extent possible in their national and regional publications. Any divergence
between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in
the latter.
5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any
equipment declared to be in conformity with an IEC Publication.
6) All users should ensure that they have the latest edition of this publication.
7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and
members of its technical committees and IEC National Committees for any personal injury, property damage or
other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and
expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC
Publications.
8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is
indispensable for the correct application of this publication.
9) Attention is drawn to the possibility that some of the elements of this IEC Publication may be the subject of
patent rights. IEC shall not be held responsible for identifying any or all such patent rights.

This publication has been drafted in accordance with the ISO/IEC Directives, Part 2. Recipients
of this document are invited to submit, with their comments, notification of any relevant patent
rights of which they are aware and to provide supporting documentation.
This working draft of the International Standard IEC 62351 Part 8 has been prepared by IEC
technical committee 57: Working Group 15 on Data and Communications Security.
It is part of the standard series IEC 62351, a set of specifications for data and communication
security. At time of publication of this part, the standard series IEC 62351 comprises the
following parts:

IEC 62351-1: Data and Communication Security Introduction and Overview

IEC 62351-2: Data and Communication Security Glossary of Terms

IEC 62351-3: Communication Network and System Security Profiles Including

TCP/IP. These security standards cover those profiles used by ICCP, IEC 60870-5 Part
104, DNP 3.0 over TCP/IP, and IEC 61850 over TCP/IP.

62351-8/CD IEC(E)

57/1001/CD

IEC 62351-4: Communication Network and System Security Profiles Including MMS.
These security standards cover those profiles used by ICCP and IEC 61850.

IEC 62351-5: Data and Communication Security Security for IEC 60870-5 and
Derivatives (i.e. DNP 3.0). These security standards cover both serial and networked
profiles used by IEC 60870-5 and DNP.

IEC 62351-6: Data and Communication Security Security for IEC 61850 Profiles.
These security standards cover those profiles in IEC 61850-7-2 that are not based on
TCP/IP GOOSE, GSSE, and SMV.

IEC 62351-7: Data and Communication Security Management Information Base (MIB)
Requirements for End-to-End Network Management. These security standards define
Management Information Base (MIBs) that are specific for the power industry, to handle
network and system management through SNMP-based capabilities.

62351-8/CD IEC(E)

5771001/CD

INTRODUCTION
This document provides a technical specification for access control in power systems. The
power system environment supported by this specification is enterprise-wide and extends
beyond traditional borders to include external providers, suppliers, and other energy partners.
Driving factors are the liberalization of the energy sector, the increasingly decentralized
generation of energy, and the need to control access to data of precious resources. This
specification supports a distributed security environment in which security is also a distributed
service.
The power system sector is continually improving the delivery of energy by leveraging technical
advances in computer-based applications. Utility operators, energy brokers and end-users are
increasingly accessing multiple applications to deliver, transmit and consume energy in a
personalized way. These disparate applications are naturally connected to a common network
infrastructure that typically supports protection equipment, substation automation protocols,
inter-station protocols, remote access and business-to-business services. Consequently,
secure access to these distributed and often loosely coupled application is even more
important than any access to an application running on a stand-alone device.
Secure access to legacy computer-based applications involves authentication of the user to the
application using single-factor identification, such as a password. After authentication, the
application determines the level at which a user can use the application. This level of authority
for a user is typically done, if at all, by each application. Sometimes users associated to groups
or roles using a local database or simply a flat file under the control of the application
administrator.
The use of local mechanisms for authorization creates a patchwork of approaches difficult to
uniformly administer across the breadth of a power system enterprise. Each application
decides on its logic the authorization. If applications can use a network, a database can serve
as trusted source of users group or role affiliation. Thus, the access to shared user base can
be controlled centrally. Each application can then examine the rights listed for a subject and
corresponding role and determine their level of authorization.
Referring to the generic AAA architecture of RFC2903, the PUSH model is used in that the
credential including the role is pushed into the target device for verification. All credentials
have a lifetime and are subject to expiration. This entails the advantage of local verification of
the credentials validity for field devices at remote sites without access to a centralized
repository.
At the net-control level the credentials can be embedded into service-oriented architectures via
XACML/SAML for automated agents including validation of credentials validity at a centralized
repository in retrospect.
Three different credential formats are supported as three different profiles. Two of them are
X.509 credentials and the third is a software token similar to Kerberos. They can be used over
TCP/IP and serial communication links.
This specification defines role-based access control (RBAC) for enterprise-wide use in power
systems. It supports a distributed or service-oriented architecture where security is distributed
service and applications are consumers of distributed services.

62351-8/CD IEC(E)

57/1001/CD

IEC 62351: DATA AND COMMUNICATION SECURITY

Part 8: Role-based access control for power system management

1
1.1

Purpose and Scope

Purpose

The scope of this technical specification is the access control of users and automated agents,
in the following called subjects, to data objects in power systems by means of role-based
access control (RBAC). RBAC is not a new concept; in fact, it is used by many operating
systems to control access to system resources. RBAC is an alternative to the all-or-nothing
super-user model. RBAC is in keeping with the security principle of least privilege, which states
that no user should be given more rights than necessary for performing that persons job.
RBAC enables an organization to separate super-user capabilities and package them into
special user accounts termed roles for assignment to specific individuals according to their job
needs. This enables a variety of security policies, networking, firewall, back-ups, and system
operation. A site that prefers a single strong administrator but wants to let more sophisticated
users fix portions of their own system can set up an advanced-user role. RBAC is not confined
to users though, it applies equally well to automated computer agents, i.e., software parts
operating independent of user interactions. As in many aspects of security, RBAC is not just a
technology; it is a way of running a business. RBAC provides a means of reallocating system
controls, but it is the organization that decides the implementation.
1.2

Scope

Figure 1 provides a survey of an infrastructure for implementing RBAC with respect to the
generic AAA framework (figure 2) applied to the substation automation environment. First, the
management of a power corporation, as an example, decides to implement a set of security
policies, e.g., based on NERC [3]. It also assigns permissions for local execution to specific
substations (thereby realizing network segregation).

Figure 1 Overview RBAC architecture

Then, a particular substation may define additional roles and assign permissions to them
according to their needs, level of expertise or area of knowledge of their employees. The roleright mapping cannot be arbitrary, as the security policies imposed by the power corporation

62351-8/CD IEC(E)

5771001/CD

must be met by that specific substation. The role-right mapping is used for configuring the
devices of the substation. The substation management also assigns users to the roles and
issues the credentials with the roles to the users. The role-right mapping is stored in the deivce
as configuration file (termed PIP in figure 1). The user-role mapping stored in the repository
called PDP.
The scope of this specification is the lower part of figure 1, i.e., everything that is needed for
interoperability between systems from different vendors. The purpose of this specification is
therefore:

Firstly, to introduce users-roles-rights as authorization concept;

Secondly, to promote role-based access solutions for the entire pyramid in power system
management; and

Thirdly, to enable interoperability in the multi-vendor environment of substation automation

and beyond.

To achieve these goals, this part of IEC 62351 specifies the following items:

Format of credentials, including subject name for logging;

Mandatory security roles and rights for administration, audit, and maintenance;

Transmission of roles for TCP/IP and serial communications;

Extensions in data models of power systems necessary to implement RBAC; and

Verification of credentials in the target system to ensure secure access control.

1.3

RBAC and the AAA-Framework

Figure 2 depicts the generic AAA framework [25]. The subject connects to a policy enforcement
point (PEP). The PEP constructs the request based on the users attributes and information
specified in the policy information point (PIP). The users attributes will include the role. The
policy decision point (PDP) receives the constructed request, compares it with the applicable
policy through the policy access point (PAP) and returns the replies to the PEP.

Figure 2 Generic AAA framework according to RFC2903

62351-8/CD IEC(E)

57/1001/CD

The PEP is usually part of a device (object) and may have no connection to the PDP which is
often the case in substation automation where the device is a bay unit. Thus, the interface
depicted in figure 2 by dashed lines may not always exist. This is also the reason why this
specification is based on the PUSH model (see later), i.e. the crendetials are presented by the
subject to the device.

1.4

Justification

The IEC 62351 specifies end-to-end security in power systems such that secure connections
are established between applications. RBAC is recognized as a potentially efficient and safe
means to control access to data objects based policies.
Existing standards (see [4], [10], and [14]) in process control industry and access control ([25] [27]) are not sufficient as neither they specify the exact role name and associated rights nor the
format of the credentials nor the detailed mechanism by which credentials are transferred to
the target system all these information are needed though for interoperability. To overcome
this drawback, this specification defines the five items listed in the previous section.

1.5

Out of Scope

This specification does not cover topics such as:

Engineering of roles;

Defining the tasks of a security officer;

Integrating local policies in RBAC.

62351-8/CD IEC(E)

10

5771001/CD

Normative references

[1]
[2]

IEC 62351: Data and Communication Security

IEC 61850-7-2 Communication networks and systems for Power Utility Automation Basic
Information and Communication structure
North American Electric Reliability Corporation: Critical Infrastructure Protection, CIP-001 CIP009
ANSI INCITS 359-2004: Role Based Access Control
PKCS#12: Personal Information Exchange Syntax Standard
IEC 61968: Application Integration at Electric Utilities System Interfaces for Distribution
management
IEC 61970: Energy management system application program interface (EMS-API)
ISO 9594-8/ITU-T Rec. X.509 (2005) The Directory: Public-key and attribute certificate
frameworks
IEC 62400: Structuring principles for technical products and technical product documentation Letter codes - Main classes and subclasses of objects according to their purpose and task
IEC 62443: Security for industrial process measurement and control - Network and system
security
IEC 61784: Industrial Communications - Fieldbus Profile
ANSI X.9.69-2006: Framework for Key Management Extensions
ANSI X.9.73-2002: Cryptographic Message Syntax
IEEE 802.1X-2004: IEEE Standard for Local and metropolitan area networks Port-based
Network Access Control
IEEE P1689 Trial Use Standard for Retrofit Cyber Security of Serial SCADA Links and IED
Remote Access
NIST: SP 800-82 Guide to Industrial Control Systems (ICS) Security, Second Public Draft.
EAP Tunnelled TLS Authentication Protocols (EAP-TTLS), internet Draft draft-ietf-pppext-eapttls-o5.txt, IETF, November 2004.
IEC/ISO 9798-2: Information technology -- Security techniques -- Entity authentication -- Part 2:
Mechanisms using symmetric encipherment algorithms
Distributed Authentication in Kerberos using Public Key : http://www.mit.edu/~kerberos/
Fast revocation method of digital certificates with hash chains:
http://www.cs.dartmouth.edu/~pki02/Micali/paper.pdf
The Keyed-Hash Message Authentication Code: http://csrc.nist.gov/publications/fips/fips198/fips198a.pdf
Extensible Access Control Markup Language (XCAML) v2.0, February, 2005.
XACML Profile for Role Based Access Control (RBAC): Committee Draft 01 (normative; 13
February 2004)
http://code.google.com/p/enterprise-java-xacml/
RFC2903: Generic AAA Architecture
RFC2094: AAA Authorisation Framework
RFC2905: AAA Authorisation Application Examples

[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]

62351-8/CD IEC(E)

11

57/1001/CD

Terms and definitions

In addition to the definitions in [1], the following terms are defined for this document.
Area of
Responsibility

Range of authority, based on network segregation.

Automated Agent

A computer program running one a single machine. It performs local

and/or remote operations independent of User inputs.

Credential

Evidence or testimonials concerning one's right to credit, confidence, or

authority.

Object

As used in this standard, an object can be any system resource subject

to access control such as a file, printer, terminal, database record, etc.

Operation

An operation is an executable image of a program which upon invocation

executes some function/activity for the User.

Permission

Permission is an approval to perform an Operation/execute a Service on

one or more RBAC protected objects.

Privilege

An attribute or property assigned to a Subject by an authority.

Privilege
management
infrastructure
(PMI)

The infrastructure able to support the management of Privileges in

support of a comprehensive authorization service and in relationship
with a Public Key Infrastructure.

Right

= Privilege, used interchangeably with Privilege.

Role

A Role is a job function within the context of an organization with some

associated semantics regarding the authority and responsibility
conferred on the User assigned to the role.
A Role subsumes a set of Rights.

Service

Permission in the context of IEC 61850.

Session

An encounter between a User and an application or with the computer in

general. One User session is the time between starting the application
and quitting.

Static separation
of duty (SSD)

Separation of duty relations are used to enforce conflict of interest

policies. Static Separation of Duty means to enforce constraints on the
assignment of Users to Roles. Membership in one Role may prevent the
User from being a member of one or more other Roles, depending on
the SSD rules enforced.

Dynamic
separation of duty
(DSD)

DSD specifications limit the availability of the rights by placing

constraints on the roles that can be activated within or across a users
sessions.
DSD provides the capability to address potential conflict-of-interest
issues at the time of a user is assigned to a role. DSD allows a user to
be authorized for roles that do not cause a conflict-of-interest when

62351-8/CD IEC(E)

12

5771001/CD

acted in independently, but which produce policy concerns when

activated simultaneously. Although this separation of duty could be
achieved through the establishment of a static separation of duty
relationship, DSD relationships generally provide the enterprise with
greater operational flexibility.
Subject

A User or an Automated Agent is a Subject. A Subject is a right holder. It

shall have a name attribute. The value is mandatory. It is this name that
shall be used to enrol a Subject in a particular role.

Token

A physical instance of a credential.

User

A User is defined as a human being.

62351-8/CD IEC(E)

13

57/1001/CD

Abbreviated terms

AA

Attribute Authority

AAA

Authentication Authorization Accounting

ACL

Access Control List

ACRL

Attribute Certificate Revocation List

ACSI

Abstract Communication System Interface

AoR

Area of Responsibility

CRL

Certificate Revocation List

EAP

Extensible Authentication Protocol

HMAC

Keyed-Hash Message Authentication Code

IED

Intelligent Electronic Device; stands for a field device, a gateway or a PC

in the net control centre.

ID

Identity

IS

International Standard

ISA

Instrument System and Automation Society

LDAP

Lightweight Directory Access Protocol

LD

Logical Device

LN

Logical Node

OCSP

Online Certificate Status Protocol

PAP

Policy Access Point

PDP

Policy Decision Point

PEP

Policy Enforcement Point

PIP

Policy Information Point

PKI

Public key infrastructure; The complete set of processes required to

provide encryption and digital signature services.

PMI

Privilege management infrastructure; The complete set of processes

required to provide an authorization service.

R2R

Role-to-Right

62351-8/CD IEC(E)

14

RBAC

Role-based Access Control

S2R

Subject-to-Role

SCL

Substation Configuration description Language

SOA

Source of Authority

5771001/CD

62351-8/CD IEC(E)

15

57/1001/CD

RBAC Process model (informative)

The purpose of an access control mechanism is to protect system resources, formally called
objects. For a system that implements RBAC, system resources can represent information
containers (e.g., files, directories in an operating system and/or columns rows, tables, and
views within a database management system) or objects that represent exhaustible device
resources, such as printers, disk space, and CPU cycles.
Role-based access control (RBAC) is a technology that has the potential to reduce the
complexity and cost of security administration in networks with large numbers of intelligent
devices. Under RBAC, security administration is simplified through the use of roles and
constraints to organize subject access levels. RBAC reduces costs within an organization
primarily because it accepts that employees change roles and responsibilities more frequently
than the rights within roles and responsibilities.

5.1

Privilege management infrastructure

RBAC is part of a general AAA infrastructure required for access control to data.
The subject must provide information (e.g. software token) along with a request to the verifier
(push) or the verifier can get the required information from a trusted source (pull) directly or via
an agent (agent).
5.1.1

Use of push or pull

In general, the subject has rights assigned by the enterprise domain authorities pushed or
pulled to the verifying entity (at run-time or through provisioning). In deciding whether to employ
a push or pull model, several factors should be considered:
PUSH:

Token holding authentication information must be sufficiently secure.

Token must have a short time to live to prevent replay attacks.

Token must be validated against an authentication service, e.g. a revocation list.

Token exchange should be encrypted to prevent its reuse (replay attack).

PULL:

Authentication service must be accessible;

A trusted communication path to the authentication service is required;

No computational overhead associated with verification of token;

Pulled authentication information is always current.

Because of the fact that protection equipment in a substation automation environment can be
located at remote places without permanent connection to a centralized repository, this
specification is based on the PUSH model. This entails that the credential pushed into the
device is issued by a central instance outside the device and subject to lifetime expiration.

62351-8/CD IEC(E)
5.2

16

5771001/CD

Separation of subjects, roles, and rights

A model for RBAC including separation of duty (static as well as dynamic) is given in figure 3.

Figure 3 Diagram of a RBAC with static and dynamic seraration of duty according to [4]
The arrows in figure 3 indicate relationships (e.g., a subject can be assigned to one or more
roles, and a role can be assigned to one or more subjects). This arrangement provides great
flexibility and granularity in assigning rights to roles and subjects to roles. Without these
conveniences there is a danger that a subject may be granted more access to resources than
is needed because of limited control over the type of access that can be associated with
subjects and resources. Any increase in the flexibility of controlling access to resources also
strengthens the application of the principle of least right.
Each session is a mapping of one subject to possibly many roles, i.e., a subject establishes a
session during which the subject activates some subset of roles that it is assigned to. Each
session is associated with a single subject and each subject is associated with one or more
sessions.
The main components of RBAC are thus: subject, role, right for operations and objects, and
session.
There are two mappings between these components that need be configured by the
administrator:

Subject-role (S2R) mapping termed subject assignment; and

Role-right mapping (R2R) termed right assignment.

Figure 4 gives a survey of subjects, roles, rights, and operations in the scope of the IEC 61850
standard.

62351-8/CD IEC(E)

17

57/1001/CD

Figure 4 User, roles, rights and operations

A right consists of a set of operations. The operations available are determined by the data
model in use; e.g. a protection system may use the IEC 61850 data model. This specification
supports data models for power systems as listed in Section 6.3.
A set of roles and associated rights must be defined to enable interoperability. These so-called
pre-defined roles and pre-defined rights are encircled by grey boxes in figure 4. The represent
the core part of this specification and are defined in Section 6. The pre-defined rights represent
an abstraction layer towards the underlying data models.
In addition to these pre-defined roles and pre-defined rights, vendors may preinstall some
device-specific right when deploying a system (represented with a white box in figure 4).
Further, roles can also be defined through substation management for their individual needs
(represented with a white box in figure 4).
5.2.1

Subject assignment

The subject assignment or subject-role mapping is stored outside the system in a repository,
e.g. LDAP as shown in figure 1. The repository may be accessed by the system to verify the
validity of the credential submitted by the subject to the system.
One or more subjects can be assigned to one or more roles.
The time period during which a particular subject-role mapping is valid should be kept flexible.
For security reasons it should be quite short.
5.2.2

Right assignment

The right assignment or role-right mapping is stored inside the system. It represents the
configuration of the device and depends on the data model in use.
This mapping is also determined by security/safety regulations and is thus the main focus of
this specification. Pre-defined roles and pre-defined rights are used to implement such policies.

62351-8/CD IEC(E)

18

5771001/CD

A right belongs to at least one role.

Note: subject assignment and right assignment can have different life-cycles. To assure
consistency they shall be equipped with a version number (e.g.: revision number) which must
be checked in the device (see also 9.1). Otherwise a role can be presented to a device by
implicitly assuming a different right assignment than the one stored in the device.
5.2.3

Operation assignment

The mapping between operations and rights is given by the data model in use. Please refer to
Section 6.3.

5.3

General architecture components of the RBAC model (roles, rights, formats,

transport, verification)

Figure 5 shows the lower part of figure 1 when a subject wants to access from system A an
object (e.g.: an application) on system B.
We assume that the devices are properly configured, i.e. the role-right assignment has been
loaded into system B and user-role assignment with corresponding version is stored in the
repository.
The small letters define the access control mechanism (the PUSH model with respect to the
AAA framework), i.e.:
a. First, the subject authenticates itself from system A towards a repository for retrieval of his
credentials and roles;
Note: This step may be optional if the user is already in possession of his credentials.
b. The repository provides the subject with his credentials and roles;
Note: This step may be optional if the user is already in possession of his credentials.
c. The subject submits its credential and its role from system A to the system B; this can be
done online or offline; the mapping is a one-to-many, i.e. the credential is valid for all
system B; restriction are optional;
d. System B verifies the credentials and gives the subject authorized access to the object
according to the right(s) associated with the role inside the credential;
Optionally, system B may verify whether the credential has not been revoked by accessing
the repository; thereby the repository serves as a policy decision point (PDP);
The configuration of the role-right assignment is a prerequisite to enforce RBAC and must
be undertaken in the scope of an engineering process.
e. Acknowledgement of system B to system A.
The process outlined from item a. to item e. is similar to Kerberos with PKI [19]. The repository
takes the function of a ticketing server. It issues a credential with limited lifetime for system A
to authenticate towards system B.

62351-8/CD IEC(E)

19

57/1001/CD

Figure 5 Schematic view of authorization meachnism based on RBAC

This specification focus on the numbered parts in figure 5 that are:
1. Formats of credentials to include roles;
2. Security roles and associated rights;
3. Methods to transport securely the authorization information to the system using existing
protocols in substation automation; and
4. Verification of credentials by a system.

5.4

Management of subject rights

We distinguish between two variants to manage subject rights

Storage of rights in a digitally signed credential; or

Centralized storage of rights in a repository (e.g., in an LDAP-enabled service).

This specification bases on the first variant and uses a public-key certificate, an attribute
certificate, an XACML attribute, or a software token as container for the credential.

5.5
5.5.1

Criteria for defining roles

Policies

A minimal set of roles is defined by policies and standards (such as this one). These roles are
mandatory and are called pre-defined roles.
Vendors of substation protection equipment, as an example, may deploy their equipment with a
set of additional roles. These roles are called default roles and may serve vendors specific
configuration procedures and/or vendor specific handling of the equipment.
Finally, roles may be defined by the power corporation and/or the substation management to
meet their specific needs (e.g. local implementation requirements). These roles are termed
specific roles.

62351-8/CD IEC(E)
5.5.2

20

5771001/CD

Introducing roles reduces complexity

Without roles, the complexity of the subject right assignment amounts to

O( s ri ),

Eq. 1

where s is the number of subjects and ri is the number of rights.

Inserting roles results in two mappings, one mapping of subjects to roles and the other roles to
rights. The complexity of these two mappings yields

O( s ro ) + O( ro ri )

Eq. 2

where ro is the number of roles. Eq. 2 can be smaller than Eq. 1. In fact, this is always the
case if the number of roles is smaller than the half of the minimum of the number of subjects
and rights. Thus, the concept of roles is recognized as a possibly efficient means to control
access rights.
5.5.3

Separation of duty does not increase complexity

Separation of duty does not increase complexity, for SoD can equally well be realized with an
additional role or an additional subject.

62351-8/CD IEC(E)

21

Role definitions (normative)

6.1

Credentials

Credentials are used to identify subjects.

6.1.1

Profiles

Three different formats of credentials are supported:

Profile A: X.509 ID certificates with extensions;

Profile B: X.509 attribute certificates;

Profile C: Software tokens.

6.1.2

Mandatory fields in credential

A credential must contain at least the following information:

Version of the credential;

Name of the subject;

Role assigned to the subject;

Issuer of the credential which equals the issuer of the role;

Time-stamp of the issuing moment;

Time-period during which the credential and thus the role is valid;

Version of the right-assignment; and

Serial number of the credential.

6.1.3

Optional fields in credentials

For all profiles:

Area of responsibility;

Extensions for local implementations.

6.1.4

Mandatory profile-specific fields

For profiles A and B only:

Signature algorithm; and

Signature value of the issuing instance.

For profile C only:

57/1001/CD

62351-8/CD IEC(E)

Hash algorithms;

Key length;

Hash value.

6.1.5

22

5771001/CD

Resolution of timestamp

The time resolution shall be at least hours.

Format: GENERALIZEDTIME according to IEC62351-4.
6.1.6

Maximal lifetime of credential

Maximal lifetime: 3 years.

Remark: the minial lifetime is an implementation issue and given by local requirements [3].
6.1.7

Size of credentials

Maximal supported size of the credentials shall be 8192 octets.

6.1.8

Number of issuers

Minimal number of supported issuers for a credential shall be three (3).

6.2

Role-right assignment

Roles shall be assigned to rights.

Remark: The rights are defined by the data model in use, see Section 6.3.
6.2.1

Number of supported rights

Minimum number of supported rights is sixteen (16).

6.2.2

Number of supported roles

Minimum number of supported roles is eight (8).

6.2.3

Flexibility of role-right mapping

The mandatory minimal role-right assignments are defined in 6.3.

Additional role-right assignment shall be allowed.

6.3
6.3.1

Role-Right assignment with respect to power systems

Power utility automation - IEC 61850

The access control for IEC 61850 data objects is to implement by the virtual access view.
Operations are called in IEC 61850 Services.
A client must be identified by the authentication parameters passed to the server.

62351-8/CD IEC(E)

23

57/1001/CD

A session must then be established along with the role of the subject and assigned to the
subject at the client side.
A subject shall then access an IEC 61850 Object simply if the required access right appears in
the access control matrix; see server class and application association model in IEC 61850-72.
There are two areas in which access control shall be applied:

Service-Access-Points: access control will be used to allow or deny remote access to a

server (e.g. a Logical Device); and

Logical-Devices: access control, shall be applied to each instance of a Logical-Device.

Access to the Logical Device shall be granted or restricted based upon service access
rights. FCD (functional constraint data).

6.3.1.1

Service access control

6.3.1.1.1

Mandatory role-right mapping

Role
Role configured in the device (see and others)

DENY

ALLOW

Right

Any other role

Additionally, a maximum number of simultaneous active associations shall be able to be

configured for a specific subject/role. The default value for any configured subject/role shall be
unlimited (e.g. bounded by the maximum number of associations supported by the server).
6.3.1.1.2

Mandatory pre-defined rights operations assignments

6.3.1.1.2.1 ALLOW Right

ACSI Service Name

Comments

Associate

Must be defined as part of access control.

Release
Abort
6.3.1.1.2.2 DENY Right
ACSI Service Name

Comments

Abort
6.3.1.2

Logical Device Access Control

For each Logical Device, in a Server, this clause specifies the types of rights that may be
configured for a particular subject/role.

62351-8/CD IEC(E)
6.3.1.2.1

24

5771001/CD

List of Mandatory Pre-defined Rights

The list of the predefined Right for a particular role shall be represented by the following
PACKED LIST:
Predefined Rights
AttributeName

AttributeType

Comments

m/o

View

BOOLEAN

Read

BOOLEAN

DataSet

BOOLEAN

Reporting

BOOLEAN

File

BOOLEAN

Control

BOOLEAN

Config

BOOLEAN

Setting Group

BOOLEAN

Management

BOOLEAN

Security

BOOLEAN

VIEW right: Allows the user/role to discover what objects are present within a Logical
Device. If this right is not granted to a user/role, the Logical Device for which the View
privilege has not been granted shall not appear.

READ right: Allows the user/role to obtain the values of objects that are present within a
logical device.

DATASET right: Allows the user/role to have full management rights for both permanent
and non-permanent DataSets.

REPORTING right: Allows a user/role to use buffered reporting as well as un-buffered

reporting.

FILE right: Allows the user/role to have restricted rights for File Services.

CONTROL right: Allows a user to perform control operations.

CONFIG right: Allows a user to remotely configure certain aspects of the server.

SETTINGGROUP right: Allows a user to remotely configure Settings Groups.

MNGT right: Allows the role to transfer substation configuration language files and other
files, as well as delete existing files.

62351-8/CD IEC(E)

25

57/1001/CD

SECURITY: Allows a user/role to perform security functions at both a Server/Service

Access Point and Logical Device basis.

6.3.1.2.2

List of Mandatory Pre-defined Roles

Table 1 Pre-defined roles according to IEC 61850
Predefined Roles

AttributeName

AttributeType

SecurityAdmin

UNICODE STRING64

Security-Audit

UNICODE STRING64

RBACMaintenance

UNICODE STRING64

6.3.1.2.3

Comments

m/o

Mandatory Role-Right Mapping

It is recommended that the following roles be considered as the minimum to be supported.

Table 2 List Pre-defined roles and right assignment (IEC 61850 service/rights)

RBACMaintenance

6.3.1.2.4

SECURITY

MNGT

Security-Audit

SETTINGGROUP

CONFIG

CONTROL

DATASET

FILE

READ

SecurityAdmin

Role

REPORTING

VIEW

Right

x
x

Definition of Mandatory Rights

6.3.1.2.4.1 All Rights other than Security Rights

The operations assignment of these roles is relegated to IEC 61850.
Informative example: View Right.
This right allows the subject/role to discover what objects are present within a Logical Device.
If this right is not granted to a subject/role, the Logical Device for which the View right has not
been granted shall not appear within the response to the ACSI Get-Logical-Device-Directory.

62351-8/CD IEC(E)

26

5771001/CD

If the View right is granted to a subject/role, then the subject/role shall have access to objects
in the Logical Device, through the following ACSI services:
ACSI Service

Comment

GetLogicalNodeDirectory

Allows all logical nodes within the specific

Logical Device to be known to the client.

GetDataDirectory
GetDataDefinition
GetDataSetDirectory

6.3.1.2.4.2 Security right

This right allows a user/role to perform security functions at both a Server/Service Access
Point and Logical Device basis.
The following modifications need be made to IEC 61870-7-3 to add visibility to subject, role and
access rights

Add the following to Table in Clause 5 (IEC 61850-7-3):

AC_SEC_M: The attribute is mandatory if Security is supported.

Add the following to LPL in Table 47 (IEC 61850-7-3):

CredName

UNICODE STRING64

ST

Right

AccessRight

ST

Add the following to clause 8, Table 49 (IEC 61850-7-3):

CredName: Value shall be the configured name that is used to represent the credentials
received for authentication.
Right: Shall be a set of rights as shown in figure 4.

6.3.1.3

Logging

Upon a successful authentication and association, the server shall log the subject and allowed
roles, to a Log named Security-Audit. The implementation of this log is defined in the specific
communication service mapping (SCSM) of IEC 61850 (It is called Service Tracking, and
applies to all services).
6.3.1.4

Roles for executives

Executive shall be assigned a passive role without access to the reporting / logging data.
Remark: Executives must obey the security policy enforced by the security officer.

62351-8/CD IEC(E)
6.3.1.5

27

57/1001/CD

Configuration of devices

The configuration shall be performed in out-of-band manner (e.g., manually) via SCL.
The configuration of the right-assignment must have a versioning number.
6.3.2

CIM IEC 61968

-- Input from questionnaire.

6.3.3

AMI

-- Input from questionnaire.

6.3.4

DA

-- Input from questionnaire.

6.3.5

Markets

-- Input from questionnaire.

6.4

Role-Right Assignment with respect to other Non-Power System domains (e.g.

industrial process control)

-- Input from questionnaire.

62351-8/CD IEC(E)

28

5771001/CD

Role formats (normative)

7.1

Profile A: X.509 ID Certificate with extensions

X.509 defines a certificate in ASN.1 notation as follows

Certificate
version
serialNumber
signature
issuer
validity
subject
subjectPublicKeyInfo
issuerUniqueIdentifier
subjectUniqueIdentifier
extensions

::=
[0]

[1]
[2]
[3]

SIGNED{SEQUENCE{
Version DEFAULT v 1
CertificateSerialNumber
AlgorithmIdentifier
Name
Validity
Name
SubjectPublicKeyInfo
IMPLICIT UnqiueIdentifier OPTIONAL
IMPLICIT UnqiueIdentifier OPTIONAL
Extensions}}

To become an ID certificate, the subject must contain the name of the Subject.
The extensions defined for X.509 v3 certificates provide methods for associating additional
attributes with users/devices (e.g. nationality of the user) or public keys and for managing a
certification hierarchy. The X.509 v3 certificate format also allows communities to define
private extensions to carry information unique to those communities.
subjectDirectoryattributes

::=

SEQUENCE SIZE (1..MAX) of Attribute

Attribute

::=

SEQUENCE {
type
AttributeType,
value
SET OF AttributeValue
-- at least one value is required --}

AttributeType

::= OBJECT IDENTIFIER

AttributeValue

::= ANY

For the purpose of this standard, two types are used

7.1.1

attributeType1:

Role

value1:

See (6.3.1.2.2)

attributeType2:

AoR

value2:

IP address and subnetmask

Field of applications (informative)

X.509 ID certificates with extensions are suitable in environments when one or more of the
following are true:

Lifetime of the right(s) encapsulated by a role is aligned with that of the public-key included
in the certificate;

The same physical entity is acting both as certificate authority and as attribute authority;

Delegation is permitted, but for any one delegation, all rights in the certificate have the
same delegation parameters and all extensions relevant to delegation apply equally to all
rights in the certificate.

For further information please refer to [8].

62351-8/CD IEC(E)
7.2

29

57/1001/CD

Profile B: X.509 Attribute Certificate

According to X.509 an attribute certificate has the structure as shown in table 3.

Table 3 Attribute certificate structure

Field

Meaning

Version

Version number of the format

Holder

Reference of the ID Certificate of the Subject

ID (Name) of the Subject or

ID of the CA and serial-number of the ID-certificate of the Subject

Issuer

Reference to the ID certificate of the attribute authority

Signature

Algorithms used for signature

SerialNumber

Serial number of the certificate

attCertValidityPeriod

Period of validity

notBeforeTime
notAfterTime
Attributes

Certified attributes

issuerUniqueID

Exact specification of the attribute authority

extensions

Extensions

Roles provide a means to directly assign rights to subjects. Subjects are issued role
assignment certificates that assign one or more roles to them through the role attribute
contained in the certificate.
role ATTRIBUTE

::={

WITH SYNTAC
ID
RoleSyntax ::= SEQUENCE{
roleAuthority
roleName

RoleSyntax
id-at-role}
[0]
[1]

GeneralNames
GeneralName}

OPTIONAL,

The roleAuthority identifies the recognized authority that issued the role certificate.
The roleName component identifies the role to which the user is assigned to.
7.2.1

Field of applications (Informative)

X.509 attribute certificates are suitable in environments when on or more of the following are
true:

Lifetime of the right is differs from that of the users public-key certificate validity;

62351-8/CD IEC(E)

30

5771001/CD

The right is valid only during certain intervals of time which are asynchronous with that
users public-key validity or with validity of other rights;

A different entity is responsible for assigning a particular right to a subject than for issuing
public-key certificates to the same subject;

There are a number of rights assigned to the subject from a variety of issuing authorities.

The attribute certificate may form an own certificate hierarchy and be completely independent
of the ID certificates.
Attribute certificates can also form a sub-tree in a PKI in that the certificate of the SOA is
signed by the root of the PKI.
For further information please refer to [8].

7.2.2

Mapping between ID and Attribute Certificate (informative)

Table 4 Mapping between PKI and PMI

Concept

PKI

PMI

Name of certificate

ID certificate

Attribute certificate

Certified contents

ID for the public key

ID for the attribute

Issuer of the certificate

Certificate authority (CA)

Attribute authority (AA)

Certified holder

Subject

Subject

Revocation

CRLs

ACRLs

Anchor of trust

Root-CA

Source of Authority

7.3

Software Token

The software token is an unsigned sequence defined as follows:

token

::=

UNSIGNED{
HASHED{
SEQUENCE{
Version of Credential;
Name of the Subject;
Role assigned to the Subject;
Issuer of the credential;
Time-stamp of the issuing moment;

62351-8/CD IEC(E)

31

57/1001/CD

Time-period during which the credential is valid;

Serial number of the credential;
Version of Right-Assignment;
Hash Algorithms;
Key length;
Extensions (OPTIONAL);}
Hash Value of the SEQUENCE}
}
Note: For bandwidth efficiency reasons the token is not signed, but hashed. This demands
though for a secure transmission.
7.3.1

Hash function

HMAC according to FIPS 196 [21]:

Supported hash Algorithm: SHA-1, SHA-256, MD5.

7.4

Distribution of the credentials

The distribution of the credentials to the Subject is an administrative task and is handled on an
on-demand basis.
Profile A (see 6.1.1): Distribution of credentials must be done in a secure way, i.e., an out-ofband manner.
Profile B (see 6.1.1): Distribution of credentials must not be done in a secure way, as the
attribute certificate is bonded to the ID certificate.
Profile C (see 6.1.1): Distribution of the credentials to the calling subject is done on an ondemand basis.

7.5

Extension for the credential (informative)

The following extensions to the credential are optional:

Area of responsibility: Area within which the credential is valid, used for network
segregation;

Revocation: Supported revocation methods (see also 9.2);

Policy: List of supported policies;

Delegation.

62351-8/CD IEC(E)

32

5771001/CD

Transport profiles (normative)

Generally, it is a two phase process to send the role information.

Phase 1 Establish a secure session, where applicable.
Phase 2 Authorization process which comprises the hand-over of the credential (incl. role).

8.1
8.1.1

Usage in Ethernet-based protocols

Profile A: X.509 ID Certificate with extensions

Phase 1 transport layer: TLS v1.1 opens a secure tunnel based on X.509 ID certificates.
Phase 2 application layer: X.509 ID (user) certificates are transmitted, e.g. via MMS as given
in IEC 62351-4.
Note: The role is transmitted over a secure tunnel.
8.1.2

Profile B: X.509 Attribute certificate

Phase 1 transport layer: TLS v1.1 opens a secure tunnel with X.509 ID certificates.
Phase 2 application layer: X.509 ID (attribute) certificates are transmitted.
8.1.3

Profile C: Software Token

Phase 1 transport layer: TLS v1.1 opens a secure tunnel with X.509 ID certificates.
Phase 2 application layer: software tokens are transmitted.

8.2

Usage in non-Ethernet based protocols

Non-Ethernet based protocols subsume serial communications.

The credentials are transmitted in encrypted form during challenge-respone authentication
between subject and device using symmetric pre-shared keys (see IEC 62351-5 and [18] for
explanation of the mechanism).
The pre-shared keys are the secret shared among the system/device and the subject. The
distribution and maintenance of the symmetric keys follows IEC 62351-5.
This method is irrespective of the profile in use, i.e., profile A, B, or C.

62351-8/CD IEC(E)

33

57/1001/CD

End device verification of credentials

9.1

Items to be verified (normative/optional)

Mandatory:

Time-period of credentials;

Comparison of the version for right-assignment in the credential with the version of
configuration in the device;

Optional:

AoR: For use of network segregation;

Issuing instance;

Profile version;

Depending on profile:

Integrity of certificate/ticket/token;

Verification of signatures of certificates to the CA root.

9.2

Revocation lists (optional)

9.2.1

General

It is recommended to prefer a restricted life-time of the credential over the utilization of

revocation lists as not all devices will have on-line access to a CRL. Revocation methods are
thus optional and can be used after local verification.
In case of Profile A (Extensions to ID Certificate) the use of a CRL is recommended as
machine/ID certificates have usually a long lifetime.
In case of Profile B (Attribute Certificate) the need for a CRL can be subsumed by
administrative measures, i.e. with restricted lifetime of certificates.
In case of Profile C (Token) the need for a revocation list can be subsumed by administrative
measures, i.e. with restricted lifetime of tokens.
9.2.2

Supported Methods

CRL for profile A;

ACRL for profile B;

OCSP;

Hash chains as fast alternative [20].

62351-8/CD IEC(E)

34

5771001/CD

10 Interoprability
10.1 Supported credentials
Supported credentials as Credentials are:

X.509 ID certificates;

X.509 attribute certificates;

Software token as defined in 7.3.

10.2 List of Supported Profiles

Table 5 List of profiles

Profile A.
X.509 ID certificate
with extensions
Profile B:
X.509 Attribute
certificate
Profile C:
Software token
defined in 7.3

as

Ethernet based protocol

TLS according to
IEC 62351-3/4

Non Ethernet based protocol

Challenge response with preshared keys according to [18].

EAP-TTLS or
TLS with challenge response
and pre-shared keys according
to [18].
TLS according to
IEC 62351-3/4
Challenge response with preshared keys according to [18].

Challenge response with preshared keys according to [18].

Challenge response with preshared keys according to [18].

10.3 How to ensure backward compatibility (normative)

RBAC to legacy protection equipment is not possible. Retrofit of those systems is a local
implementation issue; a unified architecture is generally missing and a one-fit-all solution
difficult to realize.
Administrative measures must be installed, i.e., the network administrator shall segregate the
network into areas where RBAC is operational in areas where it is not.
The extension field in the credentials shall be used to specify the area/network segment where
the RBAC in use is valid, i.e. the AoR attribute.

10.4 How to extend the list of roles and rights

The list of roles and rights shall be extendable. The maximal length of the list is a local
implementation issue.

10.5 How to map this specification to specific authorization mechanisms

Profile A is part of a PKI.
Profile B is a PMI. For information on the combination of PKI and PMI please consult [8].

62351-8/CD IEC(E)

35

57/1001/CD

Profile C: Similar to Kerberos [19]. A PKI can be realized underneath the software token
system and is needed to access the central repository in a secure manner (see figure 5).