Iec ts 62351 8 2011

IEC/TS 62351-8:2011(E) Edition 1.0 2011-09 TECHNICAL SPECIFICATION colour inside Power systems management and associated information exchange – Data and communications security – Part 8: Role-based access control Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe đ IEC/TS 62351-8 Copyright â 2011 IEC, Geneva, Switzerland All rights reserved Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either IEC or IEC's member National Committee in the country of the requester If you have any questions about IEC copyright or have an enquiry about obtaining additional rights to this publication, please contact the address below or your local IEC member National Committee for further information Droits de reproduction réservés Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit de la CEI ou du Comité national de la CEI du pays du demandeur Si vous avez des questions sur le copyright de la CEI ou si vous désirez obtenir des droits supplémentaires sur cette publication, utilisez les coordonnées ci-après ou contactez le Comité national de la CEI de votre pays de résidence IEC Central Office 3, rue de Varembé CH-1211 Geneva 20 Switzerland Email: inmail@iec.ch Web: www.iec.ch About IEC publications The technical content of IEC publications is kept under constant review by the IEC Please make sure that you have the latest edition, a corrigenda or an amendment might have been published  Catalogue of IEC publications: www.iec.ch/searchpub The IEC on-line Catalogue enables you to search by a variety of criteria (reference number, text, technical committee,…) It also gives information on projects, withdrawn and replaced publications  IEC Just Published: www.iec.ch/online_news/justpub Stay up to date on all new IEC publications Just Published details twice a month all new publications released Available on-line and also by email  Electropedia: www.electropedia.org The world's leading online dictionary of electronic and electrical terms containing more than 20 000 terms and definitions in English and French, with equivalent terms in additional languages Also known as the International Electrotechnical Vocabulary online  Customer Service Centre: www.iec.ch/webstore/custserv If you wish to give us your feedback on this publication or need further assistance, please visit the Customer Service Centre FAQ or contact us: Email: csc@iec.ch Tel.: +41 22 919 02 11 Fax: +41 22 919 03 00 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe THIS PUBLICATION IS COPYRIGHT PROTECTED Edition 1.0 2011-09 TECHNICAL SPECIFICATION colour inside Power systems management and associated information exchange – Data and communications security – Part 8: Role-based access control INTERNATIONAL ELECTROTECHNICAL COMMISSION ICS 33.200 ® Registered trademark of the International Electrotechnical Commission PRICE CODE X ISBN 978-2-88912-723-8 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe đ IEC/TS 62351-8 TS 62351-8 â IEC:2011(E) CONTENTS FOREWORD INTRODUCTION Scope Normative references Terms, definitions and abbreviations 10 3.1 Terms and definitions 10 3.2 Abbreviations 12 RBAC process model 13 4.1 4.2 General 13 Separation of subjects, roles, and rights 14 4.2.1 General 14 4.2.2 Subject assignment 15 4.2.3 Role assignment 16 4.2.4 Right assignment 16 4.3 Criteria for defining roles 16 4.3.1 Policies 16 4.3.2 User, roles, and rights 16 4.3.3 Introducing roles reduces complexity 16 Definition of roles 17 5.1 Role-to-right assignment inside the object in general 17 5.1.1 General 17 5.1.2 Number of supported rights 17 5.1.3 Number of supported roles 17 5.1.4 Flexibility of role-to-right mapping 17 5.2 Role-to-right assignment with respect to power systems 17 5.2.1 Mandatory roles and rights for logical-device access control 17 5.2.2 Power utility automation – IEC 61850 20 5.2.3 CIM – IEC 61968 22 5.2.4 AMI 22 5.2.5 DER 22 5.2.6 Markets 23 5.3 Role-to-right assignment with respect to other non-power system domains (e.g industrial process control) 23 General architecture for the PUSH model 23 6.1 General 23 6.2 Secure access to the LDAP-enabled service 24 General architecture for the PULL model 24 7.1 General 24 7.2 Secure access to the LDAP-enabled service 26 7.3 LDAP directory organization 26 General application of RBAC access token 26 8.1 General 26 8.2 Session based approach 27 8.3 Message based approach 28 Definition of access tokens 28 9.1 General 28 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe –2– –3– 9.2 9.3 9.4 Supported profiles 29 Identification of access token 29 General structure of the access tokens 29 9.4.1 Mandatory fields in the access tokens 29 9.4.2 Mandatory profile-specific fields 29 9.4.3 Optional fields in the access tokens 30 9.4.4 Definition of specific fields 30 9.5 Specific structure of the access tokens 32 9.5.1 Profile A: X.509 ID certificate 32 9.5.2 Profile B: X.509 attribute certificate 34 9.5.3 Profile C: Software token 37 9.6 Distribution of the access tokens 37 10 Transport profiles 38 10.1 Usage in TCP-based protocols 38 10.2 Usage in non-Ethernet based protocols 38 11 Verification of access tokens 38 11.1 Normative part 38 11.1.1 General 38 11.1.2 Access token authenticity 38 11.1.3 Time period 39 11.1.4 Access token integrity 39 11.2 Optional part 39 11.3 Revocation methods 39 11.3.1 General 39 11.3.2 Supported methods 40 12 Interoperability 40 12.1 General 40 12.2 Supported access tokens 40 12.3 How to ensure backward compatibility 40 12.4 How to extend the list of roles and rights 41 12.5 How to map this specification to specific authorization mechanisms 41 Bibliography 42 Figure – Generic framework for access control 13 Figure – Diagram of RBAC with static and dynamic separation of duty according to (ANSI INCITS 359-2004) 14 Figure – User, roles, rights and operations 15 Figure – Schematic view of authorization mechanism based on RBAC 24 Figure – Schematic view of authorization mechanism based on RBAC PULL model 25 Figure – Session based RBAC approach 28 Table – List of pre-defined role-to-right assignment 18 Table – List of mandatory pre-defined rights 19 Table – Pre-defined roles 20 Table – Mandatory role-to-right mapping for service access control 21 Table – The ALLOW right 21 Table – The DENY right 21 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) TS 62351-8 © IEC:2011(E) Table – VIEW right and associated ACSI services 22 Table – Mapping between ID and attribute certificate 36 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe –4– –5– INTERNATIONAL ELECTROTECHNICAL COMMISSION POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE – DATA AND COMMUNICATIONS SECURITY – Part 8: Role-based access control 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 itself does not provide any attestation of conformity Independent certification bodies provide conformity assessment services and, in some areas, access to IEC marks of conformity IEC is not responsible for any services carried out by independent certification bodies 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 The main task of IEC technical committees is to prepare International Standards In exceptional circumstances, a technical committee may propose the publication of a technical specification when • the required support cannot be obtained for the publication of an International Standard, despite repeated efforts, or • the subject is still under technical development or where, for any other reason, there is the future but no immediate possibility of an agreement on an International Standard Technical specifications are subject to review within three years of publication to decide whether they can be transformed into International Standards IEC 62351-8, which is a technical specification, has been prepared by IEC technical committee 57: Power systems management and associated information exchange Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) TS 62351-8 © IEC:2011(E) The text of this technical specification is based on the following documents: Enquiry draft Report on voting 57/1119/DTS 57/1153/RVC Full information on the voting for the approval of this technical specification can be found in the report on voting indicated in the above table This publication has been drafted in accordance with the ISO/IEC Directives, Part A list of all the parts in the IEC 62351 series, published under the general title Power systems management and associated information exchange – Data and communications security, can be found on the IEC website The committee has decided that the contents of this publication will remain unchanged until the stability date indicated on the IEC web site under "http://webstore.iec.ch" in the data related to the specific publication At this date, the publication will be • • • • • transformed into an International standard, reconfirmed, withdrawn, replaced by a revised edition, or amended A bilingual version of this publication may be issued at a later date IMPORTANT – The 'colour inside' logo on the cover page of this publication indicates that it contains colours which are considered to be useful for the correct understanding of its contents Users should therefore print this document using a colour printer Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe –6– –7– INTRODUCTION This Technical specification covers 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 applications is even more important than access to an application running on a stand-alone object Secure access to computer-based applications involves authentication of the user to the application After authentication, the level at which a user can use the application is determined The use of local mechanisms for authorization creates a patchwork of approaches which are difficult to uniformly administer across the breadth of a power system enterprise Each application decides the authorization on its own logic If applications can use a network, a database can serve as a trusted source of user’s group or role affiliation Thus, the access to a 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 The role of a user is transported in a container called an access token of that user to the object Access tokens are created and administered by a (possibly federated) identity management tool All access tokens have a lifetime and are subject to expiration Prior to verification of the access token itself, the user transmitting the access token must be authenticated by the object The object trusts the management tool to issue access tokens with suitable lifetime This enables local verification of the access token’s validity at remote sites without the need to access a centralized repository (e.g a centralized revocation list) Three different access token formats are supported as three different profiles Two of them are X.509 Access tokens 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 a distributed service and applications are consumers of distributed services Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) TS 62351-8 © IEC:2011(E) POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE – DATA AND COMMUNICATIONS SECURITY – Part 8: Role-based access control Scope This technical specification covers the access control of users and automated agents – in the following subjects – to data objects in power systems by means of role-based access control (RBAC) RBAC is not a new concept 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 subject should be given more rights than necessary for performing that subject’s 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 however, it applies equally well to automated computer agents, i.e., software parts operating independent of user interactions The following interactions are covered by the scope of this technical specification: – local (direct wired) access to the object by a human user; – local (direct wired) access to the object by a local and automated computer agent, e.g another object at the substation; – direct access by a user to the object using the objects’ built-in HMI or panel; – remote (via dial-up or wireless media) access to the object by a human user; – remote (via dial-up or wireless media) access to the object by a remote automated computer agent, e.g another object at another substation, or a control centre application As in many aspects of security, RBAC is not just a technology; it is a way of running a business As subject names change more frequently than role names and as role names change more frequently than the rights of a data model (e.g IEC 61850), it is advisable to store the frequently changing entities (i.e the subjects names) outside the object Less frequently changing role names and rights are stored inside the object RBAC thus provides a means of reallocating system controls as defined by the organization policy The scope of this specification covers everything that is needed for interoperability between systems from different vendors The purpose of this specification is therefore: – firstly, to introduce ‘subjects-roles-rights’ as authorization concept; – secondly, to promote role-based access control for the entire pyramid in power system management; and – thirdly, to enable interoperability in the multi-vendor environment of substation automation and beyond Out of scope for this specification are all topics which are not directly related to the definition of roles and access tokens for local and remote access, especially administrative or organizational tasks, such as: – user names and password definitions/policies; Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe –8– 9.5 TS 62351-8 © IEC:2011(E) Specific structure of the access tokens 9.5.1 Profile A: X.509 ID certificate 9.5.1.1 Format X.509 (see RFC5280) defines a certificate in ASN.1 notation as follows Certificate tbsCertificate signatureAlgorithm signatureValue ::= TBSCertificate ::= SEQUENCE version serialNumber signature issuer validity subject subjectPublicKeyInfo issuerUniqueID { [0] [1] subjectUniqueID [2] extensions [3] } SEQUENCE { TBSCertificate, AlgorithmIdentifier, BIT STRING } Version must be v3, CertificateSerialNumber, AlgorithmIdentifier, Name, Validity, Name, SubjectPublicKeyInfo, IMPLICIT UniqueIdentifier OPTIONAL, If present, version MUST be v2 or v3 IMPLICIT UniqueIdentifier OPTIONAL, If present, version MUST be v2 or v3 EXPLICIT Extensions OPTIONAL If present, version MUST be v3 To become an ID certificate, the subject must contain the name of the subject (= the access token holder) The extensions defined for X.509 v3 certificates provide methods for associating additional attributes with subjects (e.g nationality of the subject) 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 RFC5280 allows the definition of private extensions to carry information unique to communities This possibility is used here to convey all subject role attributes in a dedicated structure to be used in the context of IEC/TS 62351-8 Moreover, the extension is defined to allow for multiple different role attributes to be contained Thus, the subject of the certificate can be assigned multiple roles It is a non critical standard X509v3 extension and defined in the following subclause The access token is recognized through a dedicated OID The OID value is 1.2.840.10070.8.1 reflecting the IEC/TS 62351-8 access token 9.5.1.2 Certificate attributes For the certificate format X.509v3 shall be used with the following role related attributes defined to be included in the extension The OID identifying the extension is already given through 1.2.840.10070 The specific value for the access token is 1.2.840.10070.8.1 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe – 32 – – 33 – The value for the extension is defined as following: id-IEC62351 OBJECT_IDENTIFIER::= { 840 10070 } id-IECuserRoles OBJECT_IDENTIFIER::= id-IEC62351 { } IECUserRoles::= SEQUENCE OF UserRoleInfo UserRoleInfo::= SEQUENCE { contains the role information blob IEC62351 specific parameter userRole SEQUENCE SIZE (1 MAX) OF RoleID aor UTF8String (SIZE(1 64)), revision INTEGER (0 255), roleDefinition UTF8String (0 23) OPTIONAL, optional fields to be used within IEEE 1815 and IEC60870-5 operation Operation OPTIONAL, statusChangeSequenceNumber INTEGER (0 4294967295) OPTIONAL, } RoleId::= INTEGER (-32768 32767) Operation::= ENUMERATED { Add (1), Delete (2), Change (3) } As this extension describes a sequence, it allows to associate more than one role to a subject Within any access token, there shall only be one UserRoleInfo record for any given combination of aor and roleDefinition NOTE When UTF8String encoding is used, all character sequences should be normalized according to Unicode normalization form C (see Unicode Standard Annex #15) 9.5.1.3 Algorithms and key length For the used identity certificates the following Hash functions shall be supported: – mandatory Hash-operation: SHA-1; – mandatory Hash-operation: SHA-256 NOTE The mandatory support for SHA-1 is intended for backward compatibility and affects mainly the receiver side SHA-256 must be supported and is the preferred hash algorithm to be used For the used identity certificates, the following signature functions shall be supported: – mandatory Signature-operation: RSA with a key length of 1024 Bit; – mandatory Signature-operation: RSA with a key length of 2048 Bit NOTE The mandatory support for RSA with 1024 bit keys is intended for backward compatibility and affects mainly the receiver side RSA with 2048 bit keys must be supported and is the preferred signature algorithm to be used Optional Signature-operation: ECC-based using elliptic curves defined over finite prime fields with signature algorithm ECDSA or ECGDSA (for ECGDSA, see ISO/IEC 15946-2) Recommended minimum key lengths: • 192 Bit (in combination with SHA-1); • 256 bit (in combination with SHA-256) Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) 9.5.1.4 TS 62351-8 © IEC:2011(E) Field of applications 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; thus, if the public key and the certificate is revoked, the role for the certificate holder is also revoked – The same physical entity is acting both as a certificate authority and as an 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 ISO 9594-8/ITU-T Recomendation X.509 9.5.2 9.5.2.1 Profile B: X.509 attribute certificate Format An attribute certificate is typically bound to an ID certificate of the same subject It can be seen as a temporary extension of the ID certificate According to X.509 v3 an attribute certificate is defined as follows (see also ISO 9594-8/ ITU-T Recommendation X.509): AttributeCertificate::= SEQUENCE { Acinfo signatureAlgorithm signatureValue } AttributeCertificateInfo, AlgorithmIdentifier, BIT STRING AttributeCertificateInfo::= SEQUENCE { version holder issuer signature serialNumber attrCertValidityPeriod attributes issuerUniqueID extensions } AttCertVersion version is v2, Holder, AttCertIssuer, AlgorithmIdentifier, CertificateSerialNumber, AttCertValidityPeriod, SEQUENCE OF Attribute, UniqueIdentifier OPTIONAL, Extensions OPTIONAL Attribute::= SEQUENCE { Type values } AttributeType, SET OF AttributeValue at least one value is required AttributeType::= OBJECT IDENTIFIER AttributeValue::= ANY DEFINED BY AttributeType Remark: For a given AC, each AttributeType OBJECT IDENTIFIER in the sequence must be unique That is, only one instance of each attribute can occur in a single AC, but each instance can be multi-valued AC users must be able to handle multiple values for all attribute types An AC shall contain at least one attribute That is, the SEQUENCE OF Attributes shall not be of zero length Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe – 34 – 9.5.2.2 – 35 – Certificate attributes For the certificate format X.509v3 shall be used with the following role related attributes defined to be included in the extension The OID identifying the extension is already given through 1.2.840.10070 The specific value for the access token is 1.2.840.10070.8.1 The value for the extension is defined as following: id-IEC62351 OBJECT_IDENTIFIER::= { 840 10070 } id-IECuserRoles OBJECT_IDENTIFIER::= id-IEC62351 { } IECUserRoles::= SEQUENCE OF UserRoleInfo UserRoleInfo::= SEQUENCE { contains the role information blob IEC62351 specific parameter userRole SEQUENCE SIZE (1 MAX) OF RoleID aor UTF8String (SIZE(1 64)), revision INTEGER (0 255), roleDefinition UTF8String (0 23) OPTIONAL, optional fields to be used within IEEE 1815 and IEC60870-5 operation Operation OPTIONAL, statusChangeSequenceNumber INTEGER (0 4294967295) OPTIONAL, } RoleId::= INTEGER (-32768 32767) Operation::= ENUMERATED { Add (1), Delete (2), Change (3) } As this is extension describes a sequence, it allows the association of more than one role to a subject Within any access token there shall only be one UserRoleInfo record for any given combination of aor and roleDefinition NOTE When UTF8String encoding is used, all character sequences should be normalized according to Unicode normalization form C [Unicode Standard Annex #15] 9.5.2.3 Algorithms and key length For the used identity certificates, the following Hash functions shall be supported: – mandatory Hash-operation: SHA-1; – mandatory Hash-operation: SHA-256 NOTE The mandatory support for SHA-1 is intended for backward compatibility and affects mainly the receiver side SHA-256 must be supported and is the preferred hash algorithm to be used For the used identity certificates, the following signature functions shall be supported: – mandatory Signature-operation: RSA with a key length of 1024 Bit; – mandatory Signature-operation: RSA with a key length of 2048 Bit; NOTE The mandatory support for RSA with 1024 bit keys is intended for backward compatibility and affects mainly the receiver side RSA with 2048 bit keys must be supported and is the preferred signature algorithm to be used – optional Signature-operation: ECC-based using elliptic curves defined over finite prime fields with signature algorithm ECDSA or ECGDSA (For ECGDSA, see ISO/IEC 15946-2) Recommended minimum key lengths: • 192 bit (in combination with SHA-1); • 256 bit (in combination with SHA-256) Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) 9.5.2.4 TS 62351-8 © IEC:2011(E) Field of applications (informative) X.509 attribute certificates are suitable in environments when one or more of the following are true: – lifetime of the subject-to-role assignment differs from that of the user’s public-key certificate validity; – the right is valid only during certain intervals of time which are asynchronous with that user’s public-key validity or with validity of other rights; – a different entity is responsible for assigning a particular role to a subject than for issuing public-key certificates to the same subject; – there are a number of roles assigned to the subject from a variety of issuing authorities The attribute certificate may form its own certificate hierarchy and be completely independent of the ID certificates (used for a PKI) Attribute certificates can also form a sub-tree in a PKI in that the certificate of the source-ofauthority is signed by the root of the PKI For further information, please refer to ISO 9594-8/ITU-T Recommendation X.509 9.5.2.5 Mapping between ID and attribute certificate (see Table 8) Table provides the mapping between ID and attribute certificate Table – Mapping between ID and attribute certificate 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 Certified holder Subject Subject Revocation CRLs ACRLs Anchor of trust Root-CA Source of Authority Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe – 36 – 9.5.3 – 37 – Profile C: Software token 9.5.3.1 General The software token is an unsigned sequence defined as follows: Token::= UNSIGNED{ HASHED{ SEQUENCE{ Access token type (OBJECT IDENTIFIER) Serial number of the Access Token; Revision number of role-to-right assignment; Name of the subject; RoleID assigned to the subject; Area of Responsibility; roleDefinition (OPTIONAL); Issuer of the Access Token; Time-stamp of the issuing moment; Time-period during which the Access Token is valid; Hash algorithm; Key length; Operation (OPTIONAL); statusChangeSequenceNumber (OPTIONAL); } } Extensions (OPTIONAL); } Hash Value of the SEQUENCE; The OID identifying the access token is already given through 1.2.840.10070.8.1 Using multiple access tokens for one subject allows the association of more than one role to this subject There shall only be one access token for any given combination of Area of Responsibility and roleDefinition The extension field may be used to provide further role related information 9.5.3.2 Hash function and key length HMAC shall be computed according to FIPS 198 The HMAC value is not truncated – mandatory Hash-operation: SHA-1; – mandatory Hash-operation: SHA-256 NOTE The mandatory support for SHA-1 is intended for backward compatibility and affects mainly the receiver side SHA-256 must be supported and is the preferred hash algorithm to be used Mandatory key length: A fixed key length equal to the output length of the hash functions shall be supported (160) bits for SHA-1and 256 bits for SHA-256) NOTE This requires a shared secret (key for HMAC) between the involved parties, i.e., between the token repository and the receiving peer, allowing the receiving peer to validate the token 9.6 Distribution of the access tokens The distribution of the access tokens to the subject is an administrative task and is handled on an on-demand basis via an LDAP-enabled service Profile A (see 9.5.1): The subject authenticates towards the repository (with an ID certificate or username and password or similar) and receives the access token (ID certificate) Note that this distribution path only carries the certificate To apply the certificate, the subject may need the associated private key The distribution of the associated private key is typically part of a certificate enrollment process and out of the scope of this specification An example for certificate enrollment is provided in PKCS#10 Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) TS 62351-8 © IEC:2011(E) Profile B (see 9.5.2): The subject authenticates towards the repository (with an ID certificate for instance) and receives the access token; the attribute certificate shall be tied to the ID certificate Profile C (see 9.5.3): The subject authenticates towards the repository (with an ID certificate for instance) and receives the SW token 10 Transport profiles 10.1 Usage in TCP-based protocols For TCP-based protocols, the role information encapsulated in the access token is sent in a two phase process Phase – transport layer: Establish a secure connection according to IEC/TS 62351-3 where applicable For authentication, the access token according to profile A (ID-certificate) or B (attribute certificate) are applied directly For profile A, the ID certificate is directly applied in TLS (see IEC/TS 62351-3) For profile B, the attribute certificate is transmitted according the TLS authorization extension (RFC5878) while the corresponding ID certificate is applied as required in IEC/TS 62351-3 Phase – application layer: Authorization process which comprises the hand-over of the access token containing the role As specified in 9.2, the access token can either be an ID certificate, an attribute certificate or a SW token NOTE It is also possible to apply the same access token in Phase and Phase allowing for optimization of the access token verification process 10.2 Usage in non-Ethernet based protocols Non-Ethernet based protocols subsume serial communications The access tokens are transmitted after establishing a secure, serial communication channel Secure means in this context at least authenticated as specified in IEC/TS 62351-5 This method is irrespective of the profile in use, i.e., Profile A, B, or C 11 Verification of access tokens 11.1 11.1.1 Normative part General The following subclauses depict items of the access token which shall be verified: 11.1.2 Access token authenticity Before the access token can be used, the subject shall be authenticated Authentication in this context means that a sender proves his right to use the access token Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe – 38 – – 39 – Depending on the profile and the used model (PULL or PUSH), this proof can be either – a digital signature involving the private key corresponding to the subjects certificate associated with the access token, which can be verified by the receiver together with the verification of the subjects certificate suitable for profile A and B; or – a challenge response mechanism involving an authentication credential bound to the access token suitable for all profiles requiring the use of either digital signatures or a shared key between the involved entities (subject and target peer) NOTE If the access token of Profile A or B is applied on transport layer as described in 10.1, phase 1, the token verification is being done in the context of the TLS handshake, while the role application has to be done within the application Optimization option for Profile A and B over TCP-based protocols: The verification of the ID certificate can be neglected, if the ID certificate in the application layer is the same (based on serial number and issuer) as used in the TLS protected transport layer 11.1.3 Time period Time-period of the access tokens shall be verified 11.1.4 Access token integrity For profile A and B: Signature verification of access token along the certificate chain to the CA root For profile C: Integrity checks using the pre-shared key 11.2 Optional part The following items of the access token may be verified: – Revision number (see 9.4.4.8): Comparison of the revision number for role assignment in the access token with the revision number of the configuration (right assignment) in the object; – AoR (see 9.4.4.9): For use of network segregation; – Issuing instance of the access token; – Revocation list (see 11.3); – RoleDefinition (see 9.4.4.2); – Operation (see 9.4.4.3); – Sequence number (see 9.4.4.4) 11.3 11.3.1 Revocation methods General The verification step is based on the trust relationship between the identity provider and the service provider/object: Depending on that trust, a revocation list may be obsolete E.g a CRL may not be necessary when the lifetime of the access token is less than the refresh time of the CRL (i.e less that one day according to IEC/TS 62351-3) It is recommended to prefer a restricted life-time of the access token over the utilization of revocation lists as not all objects will have on-line access to a CRL Revocation methods are thus optional and can be used after verification Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) TS 62351-8 © IEC:2011(E) Profile A – ID certificate: The use of a CRL is recommended as machine/ID certificates usually have a long lifetime The need for a CRL may be subsumed by administrative measures, i.e with a restricted lifetime of the ID certificates Profile B – Attribute certificate: The need for an ACRL can be subsumed by administrative measures, i.e with a restricted lifetime of the attribute certificates The revocation of the underlying machine/ID certificates are out of the scope of this standard Profile C – Token: The need for a revocation list can be subsumed by administrative measures, i.e with a restricted lifetime of the tokens In case of revocation requests to the identity provider, the service provider / object shall have a secured connection (by TLS/SSL) with mutual authentication to the identity provider 11.3.2 Supported methods Profile A: A CRL; according to IEC/TS 62351-3, the revocation of an ID certificate shall be checked Profile B: An Attribute CRL (ACRL) Profile C: A revocation list based on access token serial number and issuer NOTE The definition of CRL handling will be addressed in IEC/TS 62351-9 12 Interoperability 12.1 General Interoperability manufacturers means proper operability between different objects from different The interoperability is not dependent on the set of roles and associated rights definition, but on their exchange 12.2 Supported access tokens Supported access tokens are: – X.509 ID certificates as defined in 9.5.1; – X.509 attribute certificates as defined in 9.5.2; – software token as defined in 9.5.3 12.3 How to ensure backward compatibility 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 and areas where it is not The extension field in the access tokens shall be used to specify the area/network segment where the RBAC in use is valid, i.e the AoR attribute _ Under consideration Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe – 40 – 12.4 – 41 – How to extend the list of roles and rights The list of roles and rights shall be extendable The maximum length of the list is a local implementation issue 12.5 How to map this specification to specific authorization mechanisms Profile A is part of a PKI Profile B is a PMI interconnected with a PKI: For information on the combination of PKI and PMI, see ISO 9594-8/ITU-T Recommendation X.509 Profile C: Similar to Kerberos A PKI can be realized underneath the software token system and may protect the access to the central repository Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) TS 62351-8 © IEC:2011(E) Bibliography ISO/IEC 15946-2, Information technology – Security techniques – Cryptographic techniques based on elliptic curves – Part 2: Digital signatures (withdrawn) IEC 61784 (all parts), Industrial communication networks – Profiles IEC 61968 (all parts), Application integration at electric utilities – System interfaces for distribution management IEC 61970, Energy management system application program interface (EMS-API) IEC/TS 62351-9, Power systems management and associated information exchange – Data and communications security – Part 9: Cyber security key management for power system equipment IEC/PAS 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/ISO 9798-2, Information technology – Security techniques – Entity authentication – Part 2: Mechanisms using symmetric encipherment algorithms 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 1518:2010, Distributed Network Protocol (DNP3) 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 XCAML, Extensible Access Control Markup Language (XCAML) v2.0, February, 2005 PKCS#12, Personal Information Exchange Syntax Standard RFC2798, Definition of the inetOrgPerson LDAP Object Class RFC2904, AAA Architecture RFC2905, AAA Authorisation Application Examples RFC4524, COSINE LDAP/X.500 Schema RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2 RFC5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile _ Under consideration Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe – 42 – – 43 – RFC5878, Transport Layer Security (TLS) Authorization Extensions NERC CIP-001 – CIP-009, North American Electric Infrastructure Protection, NERC CIP-001 – CIP-009 Reliability Corporation: Critical ANSI INCITS 359-2004, Role Based Access Control Kerberos, Distributed Authentication in Kerberos using Public Key: http://www.mit.edu/kerberos/ FIPS198a, The Keyed-Hash Message Authentication Code: http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdf Unicode Standard Annex #15 Unicode Normalization Forms", October 2006, Davis, M and M Duerst, http://www.unicode.org/reports/tr15/ PKCS#10, Certificate Request Syntax Standard _ Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe TS 62351-8 © IEC:2011(E) Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe ELECTROTECHNICAL COMMISSION 3, rue de Varembé PO Box 131 CH-1211 Geneva 20 Switzerland Tel: + 41 22 919 02 11 Fax: + 41 22 919 03 00 info@iec.ch www.iec.ch Copyrighted material licensed to BR Demo by Thomson Reuters (Scientific), Inc., subscriptions.techstreet.com, downloaded on Nov-28-2014 by James Madison No further reproduction or distribution is permitted Uncontrolled when printe INTERNATIONAL