57/1001/CDCOMMITTEE DRAFT (CD)

IEC/TC or SC: TC 57

Project number IEC/TS 62351-8 Ed. 1.0

Title of TC/SC: Power systems management and associated information exchange

Date of circulation 2009-05-01

Closing date for comments 2009-08-07

Also of interest to the following committees

Supersedes document 57/914/NP - 57/949/RVN

Functions concerned: Safety EMC Environment Quality assurance

Secretary: Dr. Andeas Huber, Germany

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, WITH THEIR COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE 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

FORM CD (IEC) 2002-08-08

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.

62351-8/CD IEC(E) 2 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

2 Normative references...................................................................................................... 10 3 Terms and definitions ..................................................................................................... 11 4 Abbreviated terms........................................................................................................... 13 5 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

6 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

7 Role formats (normative) ................................................................................................ 28 7.1 Profile A: X.509 ID Certificate with extensions........................................................ 28

62351-8/CD IEC(E) 3 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

8 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 9 End device verification of credentials .............................................................................. 33

9.1 Items to be verified (normative/optional)................................................................. 33 9.2 Revocation lists (optional) ...................................................................................... 33

9.2.1 General ..................................................................................................... 33 9.2.2 Supported Methods.................................................................................... 33

10 Interoprability.................................................................................................................. 34 10.1 Supported credentials ............................................................................................ 34 10.2 List of Supported Profiles....................................................................................... 34 10.3 How to ensure backward compatibility (normative) ................................................. 34 10.4 How to extend the list of roles and rights ................................................................ 34 10.5 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) 4 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 non-governmental 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) 5 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) 6 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) 7 57/1001/CD

IEC 62351: DATA AND COMMUNICATION SECURITY

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

1 Purpose and Scope

1.1 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 role-right mapping cannot be arbitrary, as the security policies imposed by the power corporation

62351-8/CD IEC(E) 8 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) 9 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

2 Normative references

[1] IEC 62351: Data and Communication Security [2] IEC 61850-7-2 Communication networks and systems for Power Utility Automation Basic

Information and Communication structure [3] North American Electric Reliability Corporation: Critical Infrastructure Protection, CIP-001 CIP-

009 [4] ANSI INCITS 359-2004: Role Based Access Control [5] PKCS#12: Personal Information Exchange Syntax Standard [6] IEC 61968: Application Integration at Electric Utilities System Interfaces for Distribution

management [7] IEC 61970: Energy management system application program interface (EMS-API) [8] ISO 9594-8/ITU-T Rec. X.509 (2005) The Directory: Public-key and attribute certificate

frameworks [9] 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 [10] IEC 62443: Security for industrial process measurement and control - Network and system

security [11] IEC 61784: Industrial Communications - Fieldbus Profile [12] ANSI X.9.69-2006: Framework for Key Management Extensions [13] ANSI X.9.73-2002: Cryptographic Message Syntax [14] IEEE 802.1X-2004: IEEE Standard for Local and metropolitan area networks Port-based

Network Access Control [15] IEEE P1689 Trial Use Standard for Retrofit Cyber Security of Serial SCADA Links and IED

Remote Access [16] NIST: SP 800-82 Guide to Industrial Control Systems (ICS) Security, Second Public Draft. [17] EAP Tunnelled TLS Authentication Protocols (EAP-TTLS), internet Draft draft-ietf-pppext-eap-

ttls-o5.txt, IETF, November 2004. [18] IEC/ISO 9798-2: Information technology -- Security techniques -- Entity authentication -- Part 2:

Mechanisms using symmetric encipherment algorithms [19] Distributed Authentication in Kerberos using Public Key : http://www.mit.edu/~kerberos/ [20] Fast revocation method of digital certificates with hash chains:

http://www.cs.dartmouth.edu/~pki02/Micali/paper.pdf [21] The Keyed-Hash Message Authentication Code: http://csrc.nist.gov/publications/fips/fips198/fips-

198a.pdf [22] Extensible Access Control Markup Language (XCAML) v2.0, February, 2005. [23] XACML Profile for Role Based Access Control (RBAC): Committee Draft 01 (normative; 13

February 2004) [24] http://code.google.com/p/enterprise-java-xacml/ [25] RFC2903: Generic AAA Architecture [26] RFC2094: AAA Authorisation Framework [27] RFC2905: AAA Authorisation Application Examples

62351-8/CD IEC(E) 11 57/1001/CD

3 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

4 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 5771001/CD

RBAC Role-based Access Control

S2R Subject-to-Role

SCL Substation Configuration description Language

SOA Source of Authority

62351-8/CD IEC(E) 15 57/1001/CD

5 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) 16 5771001/CD

5.2 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 Criteria for defining roles

5.5.1 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) 20 5771001/CD

5.5.2 Introducing roles reduces complexity

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

( )risO , 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

( ) ( )riroOrosO + 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 57/1001/CD

6 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:

62351-8/CD IEC(E) 22 5771001/CD

Hash algorithms;

Key length;

Hash value.

6.1.5 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 Role-Right assignment with respect to power systems

6.3.1 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-7-2.

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

Right

Role ALL

OW

DE

NY

Role configured in the device (see and others) x

Any other role x

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) 24 5771001/CD

6.3.1.2.1 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 M

Read BOOLEAN M

DataSet BOOLEAN M

Reporting BOOLEAN M

File BOOLEAN M

Control BOOLEAN M

Config BOOLEAN M

Setting Group BOOLEAN M

Management BOOLEAN M

Security BOOLEAN M

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 Comments m/o

Security-Admin

UNICODE STRING64 M

Security-Audit UNICODE STRING64 M

RBAC-Maintenance

UNICODE STRING64 M

6.3.1.2.3 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)

Right

Role VIE

W

RE

AD

DA

TAS

ET

RE

PO

RTI

NG

FILE

CO

NTR

OL

CO

NFI

G

SE

TTIN

GG

RO

UP

MN

GT

SE

CU

RIT

Y

Security-Admin x X x x x x x x X

Security-Audit x X x

RBAC-Maintenance x X x x

6.3.1.2.4 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) 27 57/1001/CD

6.3.1.5 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

7 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 ::= SIGNED{SEQUENCE{ version [0] Version DEFAULT v 1 serialNumber CertificateSerialNumber signature AlgorithmIdentifier issuer Name validity Validity subject Name subjectPublicKeyInfo SubjectPublicKeyInfo issuerUniqueIdentifier [1] IMPLICIT UnqiueIdentifier OPTIONAL subjectUniqueIdentifier [2] IMPLICIT UnqiueIdentifier OPTIONAL extensions [3] 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

attributeType1: Role

value1: See (6.3.1.2.2)

attributeType2: AoR

value2: IP address and subnetmask

7.1.1 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) 29 57/1001/CD

7.2 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

notBeforeTime

notAfterTime

Period of validity

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 RoleSyntax ID id-at-role}

RoleSyntax ::= SEQUENCE{ roleAuthority [0] GeneralNames OPTIONAL, roleName [1] GeneralName} 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-of-band 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 on-demand 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

8 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 Usage in Ethernet-based protocols

8.1.1 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

9 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

Ethernet based protocol Non Ethernet based protocol Profile A. X.509 ID certificate with extensions

TLS according to IEC 62351-3/4

Challenge response with pre-shared keys according to [18].

Profile B: X.509 Attribute certificate

EAP-TTLS or TLS with challenge response and pre-shared keys according to [18].

Challenge response with pre-shared keys according to [18].

Profile C: Software token as defined in 7.3

TLS according to IEC 62351-3/4 Challenge response with pre-shared keys according to [18].

Challenge response with pre-shared 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).

1001-cd-form-62351-8-CD.pdfPurpose and ScopePurposeScopeRBAC and the AAA-FrameworkJustificationOut of Scope

Normative referencesTerms and definitionsAbbreviated termsRBAC Process model (informative)Privilege management infrastructureUse of push or pull

Separation of subjects, roles, and rightsSubject assignmentRight assignmentOperation assignment

General architecture components of the RBAC model (roles, Management of subject rightsCriteria for defining rolesPoliciesIntroducing roles reduces complexitySeparation of duty does not increase complexity

Role definitions (normative)CredentialsProfilesMandatory fields in credentialOptional fields in credentialsMandatory profile-specific fieldsResolution of timestampMaximal lifetime of credentialSize of credentialsNumber of issuers

Role-right assignmentNumber of supported rightsNumber of supported rolesFlexibility of role-right mapping

Role-Right assignment with respect to power systemsPower utility automation - IEC 61850Service access controlMandatory role-right mappingMandatory pre-defined rights operations assignmentsALLOW RightDENY Right

Logical Device Access ControlList of Mandatory Pre-defined RightsList of Mandatory Pre-defined RolesMandatory Role-Right MappingDefinition of Mandatory RightsAll Rights other than Security RightsSecurity right

LoggingRoles for executivesConfiguration of devices

CIM IEC 61968AMIDAMarkets

Role-Right Assignment with respect to other Non-Power System

Role formats (normative)Profile A: X.509 ID Certificate with extensionsField of applications (informative)

Profile B: X.509 Attribute CertificateField of applications (Informative)Mapping between ID and Attribute Certificate (informative)

Software TokenHash function

Distribution of the credentialsExtension for the credential (informative)

Transport profiles (normative)Usage in Ethernet-based protocolsProfile A: X.509 ID Certificate with extensionsProfile B: X.509 Attribute certificateProfile C: Software Token

Usage in non-Ethernet based protocols

End device verification of credentialsItems to be verified (normative/optional)Revocation lists (optional)GeneralSupported Methods

InteroprabilitySupported credentialsList of Supported ProfilesHow to ensure backward compatibility (normative)How to extend the list of roles and rightsHow to map this specification to specific authorization mech