IEC62351-6 Ed1 CDV commentsiec61850.ucaiug.org/2019IOP-Charlotte/IOP Test Documents/Securit… · Web viewIt is generally understood as a digital signature to be evaluated based

Voting Result on 57/2033/CDVCirculation Date: 2018-10-05 Closing Date: 2018-12-28IEC 62351-6 ED1: Power systems management and associated information exchange - Data and communications security - Part 6: Security for IEC 61850

Country Status Vote Comments ReceivedArgentina P Y - 2018-12-27Australia P Y Y 2018-12-17Austria P Y - 2018-12-19Belarus O Y - 2018-12-28Belgium P A - 2018-12-20Brazil P A - 2018-12-21Bulgaria O -Canada P Y Y 2018-12-21China P Y - 2018-12-17Croatia P A - 2018-12-28Czech Republic P Y - 2018-12-17Denmark P N Y 2018-12-28Egypt P -Finland P A - 2018-12-26France P Y Y 2018-12-20Germany P Y Y 2018-12-04Greece - - - 2018-12-27Hungary P Y - 2018-10-29India P A - 2018-12-27Iran P A - 2018-12-26Ireland O -Israel P A - 2018-12-26Italy P Y - 2018-12-19Japan P Y - 2018-12-17Korea, Republic of P Y - 2018-12-28Malaysia O Y - 2018-12-21Mexico O Y - 2018-12-27Netherlands P Y - 2018-12-12New Zealand O -Norway P A - 2018-12-28Oman O -Poland O Y - 2018-12-28Portugal P Y - 2018-12-28Romania O Y - 2018-12-10Russian Federation P Y - 2018-12-28Serbia P Y - 2018-10-22Slovakia O -Slovenia P Y - 2018-12-14South Africa P A - 2018-12-12Spain P Y - 2018-12-28Sweden P Y Y 2018-12-20Switzerland P N Y 2018-12-17The Former Yugoslav Rep. of Macedonia P A - 2018-11-05Turkey O -Ukraine P Y - 2018-10-30United Arab Emirates - - - 2018-12-26United Kingdom P Y - 2018-12-19United States of America P Y - 2018-12-10

Approval Criteria ResultP-Members voting: 24P-Members in favour: 22 = 91.7% >=66.7% APPROVEDTotal votes cast: 29 Total against: 2 = 6.9% <=25% APPROVEDFinal Decision: APPROVED

Page 1 of 29

Notes

Vote: Does the National Committee agree to the circulation of the draft as a FDIS: Y = In favour; N = Against; A = Abstention.Abstentions are not taken into account when totalizing the votes.P-members not voting: Egypt(1).

*Comments rejected because they were not submitted in the IEC Comment form.**Vote rejected due to lack of justification statement.

Page 2 of 29

Date Document Project Nr.

57/2033/CDV

MB/NC

Line number(e.g. 17)

Clause/ Subclause(e.g. 3.1)

Paragraph/ Figure/ Table/(e.g. Table 1)

Type of comment

Comments Proposed change Observations of the secretariat

CA1 103,387,387,410,414,420,423,425,450,474,490,503,519,524,644,668,680,703,728,733,735,737,738,739,785,785,

- - ed Typo: “…SV…” Add space: “… SV …” Agreed

CH-02

90 ge Can we reference a standard that is not yet released? Avoid the “chaining” of standards.

As proposed previously, IEC 61850-8-1 MMS security should reference IEC 62351-4 directly.

Disagree

DK ge The DK NC votes no on this draft as we do not find it mature enough for CDV. We find the project important, though.

Circulate the draft as CD2 before circulation as CDV2 - there is a lot of work to accomplish

Disagree

DK ge As the MAC abbreviation for message authentication code is also used for media access control, it may be less confusing if the term "integrity check value" (ICV) is used instead "message authentication code".

Consider changing MAC to ICV.Disagree. Discussed in WG15.

DK te There is little indication on what type of symmetric encryption algorithms are going to be used. 8.2.3.2 briefly mentions AES. Probably AES-256-CBC is meant. Using authenticated encryption algorithms, e.g., AES-256-GCM should be considered, as it is a less resource-

Specify symmetric key algorithms to be used.

AES-256-GCM should also be considered.

Agreed,

Will reference RFC 8052 (part of the GDOI chain) which specifies the allowed Hash and confidentiality values. Added RFC 8052

Page 3 of 29

MB/NC




Type of comment


demanding algorithm in a constrained environment.

to Normative References, changed PIC TABLE 5 . and added PIC tables for GOOSE and SMV securitiy. This provides GCM and aligns with key management.

SE5 159 2 Ed Table 2 title “Configuration Options for IEC 61850-8-1 Secure profile” is confusing as Table 2 contains un-secure options

Change table title to “Configuration Options for IEC 61850-8-1 Client/Server “

Could not locate table or text. Found G1 and changed to indicate Client/Server.

SE6 159 2 Te Table is confusing and not clear. Table 2: Configuration Options for IEC 61850-8-1 Client/Server

Use Case

ACSE Authentication

TLS

Non-Secure

None None

For use over VPNs or inter-ESP communication

Yes None

Secure (MMS conforming to IEC 62351-4)

Optional Mandatory

Partially agree. Updated PICs table.

SE21 703 Ed Spaces are missing “GOOSE andSVcontrol Please correct the spelling to “GOOSE and SV control”.

Not found in published text

SE33 836, 847

10, 13 Ed Reference to clause 9,2 (9 comma 2) Correct to 9.2 (9 dot 2) Not found in published text

DK 2 ed The title IEC 62351-4 should be changed. The year is 2018

Change the title of IEC 62351-4 to:

Part 4: Profiles including MMS and derivatives

Agreed

References were not in

Page 4 of 29

MB/NC




Type of comment


RFCs 5208, 2313, 3447 and 6234 are listed but not referenced

Change the year to: 2018

Delete the references to RFCs 5208, 2313, 3447 and 6234.

Add a reference to:

IETF RFC 2104, HMAC: Keyed-Hashing for Message Authentication

published text.

2104 is in the Bibliography already. Should not be a normative reference.

SE1 2 Ed The reference is misspelled: IED 62351-9:2017 Correct the spelling to IEC. Not found in published text.

DK 3 Change header for clause 3 to:

3 Terms, definitions and abbreviated terms

Add the following general information:

3.1 General

For the purposes of this document, the terms and definitions given in IEC TS 62351-2 and the following apply.

ISO and IEC maintain terminological databases for use in standardization at the following addresses:

IEC Electropedia: available at http://www.electropedia.org/

ISO Online browsing platform: available at http://www.iso.org/obp

Agreed.

SE2 3 Ed Some abbreviations that tare used in the document are missing in the list of “terms and definition”: ESP, KDC.

Add the missing abbreviations to the list.

DK 93 3.2 ed Missing definitions

(found some in IEC 62850-7-500)

Add the following definitions:

3.2 Terms and definitions

3.2.xelectronic security perimeter a logical border surrounding a network interconnecting critical cyber assets

Added ESP, all the others are already defined in other normative documents.

Page 5 of 29

MB/NC




Type of comment


3.2.xend-entity public-key certificate public-key certificate issued to an entity, which then acts as an end entity within a public-key infrastructure

[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509 (2016), 3.5.31]

3.2.xGOOSE publishermulticast source for time critical messages like block, trip, switch position from other IEDs

3.2.xGOOSE subscriberreceiver for time critical messages like block, trip, switch position from other IEDs

3.2.xpublic-key certificatepublic key of an entity, together with some other information, rendered unforgeable by digital signature with the private key of the CA, which issued it

[SOURCE: ISO/IEC 9594-8:2017 | Rec. ITU-T X.509 (2016), 3.5.57]

3.2.xSV publishermulticast source for time critical voltage and/or current sample streams from other IEDs

3.2.xSV subscriberreceiver for time critical voltage and/or current sample streams from other IEDs

DK 93 3.3 ed Abbreviations should be proper formatted and new ones should be added

3.3 Abbreviated terms

For the purposes of this document, the abbreviated terms given in IEC TS 62351-2 and the following apply.

Only included terms that are used in the document.

Page 6 of 29

MB/NC




Type of comment


ACSE Association Control Service Element

APDU Application Protocol Data Unit

ASDU Application Service Data Unit

ASN.1 Abstract Syntax Notation One

BER Basic Encoding Rules

CDC Common Data Classe

ESP Electronic Security Perimeter

GMAC Galois Message Authentication Code

GOOSE Generic Object Oriented Substation Event

GSE Generic Substation Events

ICT IED Configuration Tool

ICV Integrity Check Value

IED Intelligent Electronic Device

KDC Key Distribution Center

MAC Media Access Control

SMV Sampled Measured Values

SCL Substation Configuration Language

SV Sampled Value

DK 96 4 te The security threats are numerous. It could be confusing to mention just a couple implying that we have considered any possible threat.

Consider deleting clause 4.Disagree

SE3 103 4 Ed Spaces are missing in the work “andSVare” Correct the spelling to “and SV are” Not found in published text.

AU 101 4.1 Paragraph 1

te “response times” is not the right term – according to IEC 61850-5 Ed2 cl 11.1.1.4 it should be

Changed.

Page 7 of 29

MB/NC




Type of comment


“Transfer time”. Also clause IEC 61850-5 Ed2 cl 11.2.1.2 and 11.2.4 defines the required time as ≤3 ms, not 4.


ed “andSVare” to be changed to “and SV are” Was previously corrected in circulated document.


te Change “4 ms delivery” to “3 ms delivery” as per IEC 61850-5 Ed2 cl 11.2.1.2 and 11.2.4

Change “4 ms delivery” to “3 ms delivery” Agreed

CH-01

101, 105

4.1 te Where are the 4 ms coming from?IEC 61850-5 (Ed. 2.0) defines 3 ms for Raw data messages and Trip in chapter 11.2.4 and 11.2.1.2IEC 61869-9 defines 2 ms for Protective and measuring applications

Changed per 61850-5 to 3 msec.

need to discuss the need to mention 2 ms.

CH-03

132 4.3 ge Replay protection is spread across two standards.Avoid “chaining” of standards.

Keep the replay protection within IEC 62351-6. Unable to determine the chaining of standards. Appears to be all in 62351-6 in the published text.

DK 134 5 Heading ed According to IEC rules there should be a second level heading after the first level header.

Add a second level header after the 1st level header:

5.1 General (or something else)

Already done in published text.

DK 148 5 Last paragraph

te Our understanding of Electronic Security Perimeter (ESP) is that the security features provide the ESP

This paragraph should be moved to the Scope clause

Change the paragraph to:

The scope of this part of IEC 62351 is to provide an electronic security perimeter (ESP) for critical resources.

Disagree.

The point of the paragraph is to indicate that the technology specified is valiid for use within an ESP (e.g. substation) or for external communications.

AU 159 5.1 Table 2 ed Table 2 heading of 4th column change “Supprot” to “Support”

Not found In published text.

CA2 159 5.1 Table 2 ed Typo: Supprot Support Not found In published text.

CA3 159 5.1 Table 2 te The support of TLS shall be mandatory and the support for application authentication optional. Since TLS can be used easily to authenticate and secure the connection, it is useless in most case to duplicate this

Make support for TLS mandatory

Make the support for ACSE Authentication optional

TLS change made.

Disagree about ACSE

Page 8 of 29

MB/NC




Type of comment


functionality in the A-Profile. authentication support.

CH-04

153 5.1 ge Why is IEC 62351-4 referenced for TLS?Avoid “chaining” of standards.

“TLS as specified by IEC 62351-3” Disagee, 62351-4 places restrictions on -3.

CH-05

159 5.1 te Why add end-to-end application security at all? There is no added security benefit compared to ACSE over TLS.It just adds complication, reduces the chance of interoperability.

Remove end-to-end application security for 8-1 MMS.For 8-1 MMS, make TLS mandatory, ACSE optional.Where TLS means TLS Authentication and TLS encryption.

Disagree on removing E2E.

Agree.

Just referencing the definition in -4.

CH-06

159 5.1 Table 2 te What is the meaning of the first column? Add a title to the first column Added Title.

CH-07

159 5.1 Table 2 te Why does a security standard make a non-secure option mandatory?

Remove the Non-secure option.IEC 61850-8-1 “without security” can be handled in the IEC 61850-8-1 PICS statement.

Disagree,

The reason is that in order to claim compliance non-secure an secure mode most be supported. It is not conformant to only support the secure profie.

CH-08

159 5.1 Table 2 te What is the meaning of the “Authentication” column? Does this mean ACSE authentication?

Change title to “ACSE Authentication”. Was already corrected in published text.

CH-09

159 5.1 Table 2 te Why is TLS without (ACSE) authentication excluded?a) This is secureb) TLS should be mandatory

Change TLS + “ACSE Authentication None” to mandatory (for 8-1 MMS) in column “support”.Change TLS + “ACSE Authentication None” to secure (for 8-1 MMS) in the untitled first column.

Partially agree.

CH-10

159 5.1 Table 2 te TLS with (ACSE) authentication should be optional.We can (and will) do TLS mutual authentication. We don’t need ACSE authentication to be mandatory.

Make TLS + ACSE Authentication optional. Disagree,

It was agreed in WG15 that this combination was mandatory and E2E is optional.

CH-11

162 5.1 te Unclear what is meant with “no valid X.509 private certificate”There is no such thing as a private certificate.Certificates are by definition, public.

Rewrite to make the meaning clear. E.g., replace “X.509 Private Certificate” with “private key”, if that is what is meant.

Could not find in published text.

Page 9 of 29

MB/NC




Type of comment


Do we mean “private key”?

CH-12

162 5.1 te inter-ESP communication without TLS will be insecure!

Make TLS mandatory in all cases! Partial agreement,

TLS is not required if using E2E security. Updated PICs to reflect the difference.

DE-01

153 5.1 1st abstract ge Reference to IEC 62351-4 should specify the publication year to reference the intended version (appears multiple times)

Please include the year of publication in the reference throughout the document.

Disagree.

WG15 reviewed and desires to reference the latest standard.

DE-02

159 5.1 Table 2 ed Typo Please change “Supprot” to “Support”. Could not find text in published document.

DE-03

159 5.1 Table 2 te The combination of A-Profile and T-Profile is different than currently described in IEC 61850-8-1 AMD1. In this document both, the A-Profile and the T-profile are stated as conditional. Part 6 restricts this to the combination of A-Profile and T-Profile only, while the application of the T-Profile is considered sufficient, too.

Please change the “not allowed” to “transport secured” and the support from “excluded” to “optional”.Please update the “secured” to “transport secured with application level authentication” to reflect the actual functionality.

Partially agree. Updated table. Believe it takes into account the concern.

DK 151 5.1 1st paragraph

te It does not seem right that this part of IEC 62351 requires support of compatibility mode application layer security

This isagainst the recommendation in Part 4 to migrate to native mode.

Make compatibility mode optionalDisagree.

This has been discussed several times in WG15. This will be required so that current implementations can be tested and conformant. E2E was agreed to be optional this publication and eventually mandatory in Edition 2.

DK 162 5.1 Last paragraph

ed There is nothing called an X.509 private certificate.

Change: X.509 private certificateto:end-entity public-key certificate

Not found in published text

FR-1155 5.1 General

Shouldn’t TLS1.3 be at least mentioned as permitted?Disagree.

Referred to IEC 62351-3 which mandates 1.2.

Page 10 of 29

MB/NC




Type of comment


SE4 159 5.1 2 Ed Table 2: The title of column 4 is misspelled “Supprot”.

Correct the spelling to “support”. Not found in text.

SE7 181 5.1 Te Conformance to the standard requires extension of CDCs defined in IEC61850-7-3. The standard IEC61850-7-3 NameSpace (NSD) is published as a CodeComponent machine readable file on www.iec.ch (TC57 – documents – support docs). Please consider how the necessary extensions of the CDCs is best published for convenient implementation.

Please also publish the extended CDCs in a CodeComponent on www.iec.ch

Definitions are now in SCL ED 2.1. Removed definition.

DE-04

163 5.2 3rd paragraph

te A table with mandatory and optional profile combinations as done in clause 5.1 would be helpful here.

Please include profile combination overview table. Agree in concept.

Added diagram and an explanation.

DK 163 5.2 2nd & 3rd paragraphs

te This second paragraph gives the impression that the ACSE authentication mechanism is used in IEC 61850-8-2. Security information is provided in the user data of ACSE and therefore not part of the ACSE specification. The same security is provided in an XMPP stanza for, e.g., EC 61850-8-2.

What is stated in the 3rd paragraph is clearly stated in IEC 62351-4 and therefore redundant. By deleting the 3rd paragraph, we do not need to include the XMPP in subclause 3.3.

Delete paragraphs 2 and 3 of subclause 5.2Believe the resolution of DE-04 addresses the issue.

CA4 197 5.3 5 te The standard mandate the serial number to be encoded in the originatorID. This would prohibit any other uses of the existing originatorID field like an IED name or IP. The originatorID is provided by the control model and shall not be altered.

Encode the serial number field within another data attribute or combine it within the new certIssuer attribute.

Disagree.

Need both the certificate issuer and serial number. Mutliple CA’s may be in play with the same serial number.

DK 172 5.3 te This subclause is somewhat confusing.

The title does not fully reflect the content of the subclause, as the inclusion of a new attribute type is a major part of the subclause.

This subclause needs clarification. See responses (some out of order.

Added Control into title.

Page 11 of 29

http://www.iec.ch/

http://www.iec.ch/

MB/NC




Type of comment


The subclause mentioned strong authentication. It is generally understood as a digital signature to be evaluated based on the information in a public-key certificate. It is assumed that when having the issuer name, i.e., the name of the issuing CA and the serial number of the public-key certificate, then the public-key certificate can be located if available at the subscriber site.

Authentication and integrity is to our understanding provided by an ICV (or MAC) and not by a digital signature. Therefore, we need more information about how strong authentication is performed based on information in a public-key certificate.

The first bullet in the bullet list talks about multiple names in the issuer field, which assumingly is the issuer component of the public-key certificate. This component has only one name. There seems to be overlap with the second bullet, which refers to something called an x.509 issuer name.

Removed the word strong.

The use of authentication, in this clause, is for identification establishment purposes only.

Last Comment: the issuer field in a certificate is defined as: RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

Therefore a different representation is needed. Thus the specification stands as is.

CA6 227 6.2.1 - te The whole replay protection is far too complex. Also, it relies on timestamps that may not be valid if systems are not properly synchronized.

A much simpler replay protection scheme can be achieved for both GOOSE and SV using a sequential number starting from initial timestamp.

The details of this scheme are in annex CA-A1.

Refactor state machines and descriptions.

Page 12 of 29

MB/NC




Type of comment


CH-13

227 6.2.1 te The proposal could result in a valid sender being identified as an attacker, and being blocked, while the attacker is assumed to be a valid sender.

Block all senders, and raise an alarm. Refactor state machines and descriptions.

CH-14

229 6.2.1.1 te What is missing from the state machine, is monitoring for big jumps which do not equal rollover. It can happen that a second (fake) sender with a larger stNum (sqNum is unlikely in the case of a real attacker, but also possible if data rarely changes), manages to "insert itself" and then the 'real' sender with lower numbers is regarded as a replay attack/delay. A typical value would be maximum jump 5 (corresponds to 4 lost telegrams) or 10 (corresponds to 10 s time difference at maxtime = 1s). The question is what to do in this case? Setting the packet as invalid alone does not help, because then the next telegram with anything is accepted.

Block (application = invalid) until the (TAL?) Timeout, and send an alert (LGOS?) so that the 'real' sender is also stopped and restarted.

Refactor state machines and descriptions.

Have added sequence in the Ethernet extensions. Will add a sliding window , similar to IPSec, to validate sequence numbers.

SE9 381 6.2.2 Ed The sentence is strange and hard to read. “… how to transition should should out-of-order message delivery should be handled”.

Please rephrase. Refactor state machines and descriptions.

DK 388 6.2.2.1 ASN.1 te The ASN.1 is not completely correct. It is realized that it is copied from IEC 61850-9-2. ANY is not a valid specification.

The table form should not be used.

The ASN.1 should probably look like:

SavPdu ::= SEQUENCE { noASDU [0] IMPLICIT INTEGER (1..65535). security [1] IMPLICIT OCTET STRING (SIZE (8)) OPTIONAL, asdu [2] IMPLICIT SEQUENCE OF ASDU ... }

Disagree.

This matches with what is documented in IEC 61850-9-2.

SE8 326 6.2.1.2 Ed There is a redundant word “shall” in the sentence: “… and the value shall AuthenticationValue shall not…”.

Please remove the first “shall” in the sentence. Not in text supplied by IEC.

AU 414 6.2.2.2 Paragraph 2

ed “forSVmessages” to “for SV messages” Agree

AU 420 6.2.2.2 List item 1 ed “noSVsubscription” to “no SV subscription” Agree

SE10 448 6.2.2.2 Ed The subclause of the sentence is missing the complement (what is to be configured)

Please rephrase. Could not locate in provide IEC text. Will correct given further clarification.

Page 13 of 29

MB/NC




Type of comment


SE11 414 6.2.2.2 Ed Bonded words Insert space between words Agree

SE12 448 6.2.2.2 Ed Punctuation present at the beginning of sentence.

Remove punctuation Agree

SE13 450 6.2.2.2 Ed Bonded words: actualSVAPDU Please insert space between words Agree

SE14 474 6.2.2.2 Ed Bonded words: forSVpacket Please insert space between words Agree

Se15 482 6.2.2.2 Ed Add the verb shall occur in the end of the sentence

Modify to…, a transition to state 8 shall occur. In text.

SE16 486 6.2.2.2 Ed Add the verb shall occur in the end of the sentence

Modify to…, a transition to state 8 shall occur. In Text

AU 503 6.2.2.2.1 Paragraph 1

ed “checkingSVsecurity” to “checking SV security” Agree

SE17 510 6.2.2.2.1 Ed There is a redundant word “shall” in the sentence: “… and the value shall AuthenticationValue shall not…”.

Please remove the first “shall” in the sentence. Correct in text.

AU 519 6.2.2.2.2 Paragraph 1

ed “forSVpacket” to “for SV packet” Agree

CA7 529 7 - te This standard only refer to SNTP and ignore other synchronization mechanism like PTP or IRIG-B.

We should probably open the door to any secure time synchronization service.

Agree with sentiment. However, PTP is not secure currently and IEEE is working on this. IRIG-B is out-of-scope of IEC 61850.

Will put in text about 61850-9-3 is not secure. Security profile for 9-3 will be worked on when 9-3 refers to PTP (c37.238) version 2.1 which has security profile.

SE18 525 7 Te Chapter title shall refer to time synchronization mechanisms adopted by IEC 61850. SNTP is just one abbreviation and additionally PTP is also another time synchronization mechanism adopted within IEC 61850-90-3

Change the title of the chapter by referring to time synchronization mechanism and address the PTP mechanism at least in the same manner as for the SNTP.

Agree with sentiment. However, PTP is not secure currently and IEEE is working on this. IRIG-B is out-of-scope of IEC 61850.

Will put in text about 61850-9-3 is not secure.

Page 14 of 29

MB/NC




Type of comment


Security profile for 9-3 will be worked on when 9-3 refers to PTP (c37.238) version 2.1 which has security profile.

FR-2 539-540 8.1 Editorial Stroked out text. Should we keep it in final standard ? Will remove.

DK 542 8.2.1 Figure 3 ed The octet number for last APPID octet is wrong. Change '6' to '4'.Agree

DK 695 8.3 last paragraph

ed Should the last paragraph be part of 8.2.4? Changed title to key management. Changed text.

DK 564 8.2.2.1 te Bad ASN.1It is not clear for what the first reserved SEQUENCE component is used. A SEQUENCE of what? As it is now, it is illegal ASN.1. As this was also in the TS, there must be some implementation experience. The "-- do not use" should be explained.The private component is in the text described as SEQUENCE, while the ASN.1 specifies it as an OCTET STRING.

Replace the ASN.1 with:

Extension ::= SEQUENCE {--reservedA [1] IMPLICIT SEQUENCE ?? OPTIONAL, private [2] IMPLICIT OCTET STRING OPTIONAL, reservedB [3] IMPLICIT OCTET STRING OPTIONAL, -- do not use(??) authenticationValue [4] IMPLICIT AuthenticationValue, ... }

Describe the purpose of the private component.

Fixed to:

Extension::= [0] IMPLICIT SEQUENCE { [1] IMPLICIT SEQUENCE Reserved OPTIONAL, [2] IMPLICIT OCTETSTRING Private OPTIONAL, [3] IMPLICIT AuthenticationValue OPTIONAL, … }

DK 642 8.2.3 te The ampersand should be removed.

The ICV algorithm is not signalled. The paragraph just before table 4 and the table itself indicate that enumeration should be used, but that is not reflected in the ASN.1.

Change the heading to:

8.2.3 mAC componentor:8.2.3 icv component

Make a specification for how the ICV algorithm is signalled.

Agree

DK 643 8.2.3 te The first paragraph states:

"The calculated HMAC value shall be used for the authentication/integrity of the octets that

Change the first paragraph to:

The calculated ICV value shall be used for the authentication/integrity of the octets that starts with

Disagree. Staying with the terminology of Message Authentication Code.

All of the algorithms

Page 15 of 29

MB/NC




Type of comment


starts with the Ethertype Identifier for GOOSE orSVthrough the end of the GOOSE/SMV APDU. The HMAC calculations shall not include the hMAC production. The value of the parameter shall be calculated based upon the HMAC algorithm in RFC 2104."

The ICV is not necessarily a HMAC value.

The Extension as shown in Figure 3 is not included in the calculation. This seems a miss.

Not all ICVs are HMACs

the Ethertype Identifier for GOOSE or SV through the end of the Extension. The icv component shall be excluded for the ICV calculation.

Change the following paragraphs to:

The value of the icv component shall be an OCTET STRING value

The allowed ICV algorithms are HMAC-SHA256 and AES-GMAC.

Additionally, the calculated MAC value may be truncated, per RFC 2104. The allowed truncations are 80, 128, and 256 bits.

allowed by RFC 8052 are MACs.

WG15 has decided to stay with Message Authentication Code.

The text indicates encoded as ASN.1 OctetString.

The allowed algorithms are specified in RFC 8052.

Changed text.

DK 643 8.2.3 ed The text in this subclause is not clear. Not all the ICVs are of type HMAC.

The Table 4 text indicate that a MAC is a signature, which is not the case.

In table 4, second column, SHA-256 is not an HMAC algorithm, but a hash algorithm.

Column 2 of Table 4 has a wrong heading. Not all the ICVs in the column are HMACs.

The condition c1 is in contrast with the first paragraph after Table 4.

Should AES-GMAC-64 be AES-GMAC-80?

Remove the word "signature" from the Table 4 header.

In Table 4, second column, change SHA-256 to HMAC-SHA256.

Change the heading of Table 4, column 2 to ICV.

In Table 4, last column, change upper case M to lower case m.

Removed Signature

Disagree about change from MAC to ICV.

WG15 has decided to stay with Message Authentication Code.

Removed table and truncation text. Referred to PICs.

FR-5

643 8.2.3 Editorial CMAC is a MAC but isn’t HMAC.

I guess earlier the only MAC available was HMAC and it made sense to use HMAC everywhere, but now that CMAC is available one must be more careful

Replace all instances of HMAC by MAC, save for when the MAC discussed is actually HMAC, many times it can actually CMAC

Replaced where approviate.

SE20 668 8.2.3 Ed Spaces are missing “GOOSE orSVAPDU” Please correct the spelling to “GOOSE or SV APDU”.

Agree

Page 16 of 29

MB/NC




Type of comment


DK 583 8.2.2.2 ed The AuthenticationValue is not an algorithm, but a data type. The ampersand (&) should be removed

Replace the header with:

8.2.2.2 AuthenticationValue data type

Removed Alogirthm.

& needs to stay since it is referenced in 8.2.2.1

DK 673 8.2.3.1 2nd paragraph

ed There is nothing called a pubic X.509 certificate. Change:public X.509 certificateto:public-key certificate

Removed sentence.

Referred to IEC 62351-9.

DK 687 8.2.4 ed KDC is Key Distribution Center, not Key Delivery Center

KDC is specified in IEC 62351-9, not in IEC 62351-8

Replace:Key Delivery Centerwith:Key Distribution Center

Replace:IEC 62351-8with:IEC 62351-9

Agree.

FR-7 689 8.2.4 Editorial Typo Change reference to 62351-8 to 62351-9 Agree

DK 585 8.2.2.2.1 te Bad ASN.1 Replace the ASN.1 with:

AuthenticationValue ::= SEQUENCE { version [0] IMPLICIT INTEGER, timeOfCurrentKey [1] IMPLICIT INTEGER, timrOfNextKey [2] IMPLICIT INTEGER, initializationVector [3] IMPLICIT OCTET STRING OPTIONAL, keyID [4] IMPLICIT INTEGER (4), ..., ..., icv OCTET STRING }

Replaced definition, did not change to icv.

FR-6 685 8.2.3.2 Editorial Typo Substitute : /the the /the/ Agree

DK 595 8.2.2.2.2 ed The ampersand should be removed.

In first line, Version is not an attribute; version is a component of a sequence.

Consider not using subclause for every

Change the heading to:8.2.2.2.2version component

Change:Version attributeto:

changed attribute to component.

According to 8824-1 and X.6801, there is no ASN.1 basic type of UNSIGNED.

Page 17 of 29

MB/NC




Type of comment


component of a sequence.

The INTEGER universal type is not a data type for unsigned integers.

version component

Change:Unsigned integerto:positive integer

Possibly add to the ASN.1:INTEGER (0..127)

Specified that the value must be greater than 0.

Added constraint of 1..127.


In first line, TimeofCurrentKey is not an attribute, but timeOfCurrentKey is a component of a sequence.

The INTEGER universal type is not a data type for unsigned integers. This means that if an unsigned number consists of 4 octets and the first bit is '1', then the BER encoding takes 5 octets where the first octet consists of all '0's.

By extending the upper limit to 239-1 (549755813887), we can make use of all 5 octets and the overrun will be far out in the future.

Change the heading to:8.2.2.2.3 timeOfCurrentKey component

Change:TimeofCurrentKey attributeto:timeOfCurrentKey component

Change:Unsigned integerto:positive integer

Possibly add to the ASN.1:INTEGER (0..4294967295)

Removed ampersand. Changed to component.

De-capitalized unsigned and integer.

Added constraint.

FR-3 606-609 8.2.2.2.3 Editorial time_t is usually, or even always signed on Unix, (even if the standard leaves it implantation dependant http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html). On Linux, by far the most widely deployed Unix, time_t is signed. time_t also tends to be 64 bits long nowadays and this case should also be addressed. The only case of an unsigned time_t I could find was VxWorks, which is hardly an Unix.

Maybe a note that this choice of using unsigned 32 bits integers addresses the Year 2038 Problem.

Replace :

“Some operating systems have a 32-bits Unsigned value that represents SecondsSinceEpoch (e.g. Unix). For implementations in such operating systems, it shall be the implementation’s responsibility to provide the appropriate time offsets to allow the full range of the Unsigned Integer value to be used.”

with the new section :

“Some operating systems have a 32-bits Signed value that represents SecondsSinceEpoch (e.g. Unix). For implementations in such operating systems, it shall be the implementation’s

Agree. Did both of the proposed text.

Page 18 of 29

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html

MB/NC




Type of comment


https://en.wikipedia.org/wiki/Year_2038_problem

responsibility to provide the appropriate time offsets to allow the full range of the Unsigned Integer value to be used.”

Possibly adding:

“In the case of an operating system with an internal 64 bits time representation, it should be shortened to unsigned 32 bits. The choice of representation of time as an unsigned 32 bit number makes the representation not affected by the Year 2038 problem.”


In first line, TimetoNextKey is not an attribute, but timeToNextKey is a component of a sequence.

Change the heading to:8.2.2.2.4 timeToNexKeyt component

Change:TimetoNextKey attributeto:timeToNextKey component

Agree

FR-4 611 8.2.2.2.4 Editorial Typo Substitute : /an Signed Integer value /a Signed Integer value/

Should have been unsigned.

SE19 613 8.2.2.2.4 Ed The sentence is strange and hard to read. “… If the Most Significant Bit is avalue of (1), representing a negative value, shall be used to indicate that no new key has been scheduled to be placed into service”.

Please rephrase. Agreed.


Change "field" to "component"

Change the heading to:8.2.2.2.5 initializationVector component

Change:InitializationVector fieldto:initializationVector component

Changed component in text not title.

SE22 697 9.1 Ed The term skew in unclear Please provide a more thorough explanation of the terms skew and time skew.

Added definition

SE23 705 9.1 Te Skew values is required to be specified on an individual IED subscription basis. It is not clear

Please give a recommendation for how to handle skew for dynamic clients. Alternatively, mention

Added a semtemce for non-SCL configured

Page 19 of 29

https://en.wikipedia.org/wiki/Year_2038_problem

MB/NC




Type of comment


how this requirement shall be interpreted in case a client “dynamically” subscribes to a GOOSE or SMV (dynamic = live, in the running system). A dynamic client may be e.g. a testing tool client.

that Skew for this case is not covered by the standard.

subscribers making the skew detection a local issue.

DK 6.2.8 8.2.2.2.6 ed The ampersand should be removed. Change the heading to:8.2.2.2.6keyID component

Change the first part of the first line to:

The keyID component shall be the four octet value

Agree

FR-8 725 9.2.1 Editorial Non capitalized acronym Substitute : /Pdu /PDU/ Agree

SE24 718 9.2.1 Ed Misspelling “sublement” Please correct spelling. AgreeAU 733 9.2.2 Paragraph

3ed “eachSVcontrol” to “each SV control “ Agree

AU 735 9.2.2 Paragraph 4

ed “support theSVsecurity” to “supports the SV security”

Agree


ed “theSVPublisher” to “the SV Publisher” Agree


ed Both instances of “Pdu” to “PDU” Agree

SE25 725 9.2.2 Ed Abbreviation Pdu used without capitals Please use capitals PDU. Agree

SE26 733 9.2.2 Ed Spaces are missing between words “eachSVcontrol”

Correct the spacing to “each SV control”. Agree

SE27 735 9.2.2 Ed Spaces are missing between words “theSV”” Correct the spacing to “the SV publisher”. Agree

SE28 737 9.2.2 Ed Spaces are missing between words “theSVsecurity””.

Correct the spacing to “the SV security”. Agree

SE29 738 9.2.2 Ed Spaces are missing between words “theSVPdu”” Correct the spacing to “the SV PDU”. Agree

SE30 739 9.2.2 Ed Spaces are missing between words “theSVPublisher””

Correct the spacing to “the SV”. Agree

SE31 781 9.3.1 Ed Abbreviation Pdu used without capitals Please use capitals PDU. AgreeAU 749 9.2.3 Paragraph

4ed “Pdu” to “PDU” Agree


ed Both instances of “theSVPdu” to “the SV PDU” Agree

Page 20 of 29

MB/NC




Type of comment


SE32 785 9.3.2 Ed Spaces are missing between words “theSVPdu”” Correct the spacing to “the SV PDU”. Agree

FR-9757 9.2.4 Editorial Missing opening ‘<’ in XML fragment and no syntax

highlighting as in the othersAdd missing ‘<’ at beginning of fragment, add syntax highlighting as in the others XML fragments

Agree

FR-10769 9.2.5 Editorial Missing opening ‘<’ in XML fragment and no syntax

highlighting as in the othersAdd missing ‘<’ at beginning of fragment, add syntax highlighting as in the others XML fragments

Agree

CH-15

802 10.1 Table 5 ge I know that IEC 61850-8-1 doesn’t want to mention anything about security, and just “delegates” everything to IEC 62351-6.However, this leads to the situation where we have sections in -6 that belong in other standards. I have to read two, three, or four different standards to try to figure out how security for IEC 61850-8-1 is specified.In this state, it will be impossible to keep all of this consistent, and it will be impossible to get interoperability, let alone a secure solution.

Move the relevant parts of Table 5 to IEC 61850-8-1 and 8-2 respectively.

Disagree Not per agreement with 8-1 editors.

It is true for IEC 61850-8-2 and that is not included in -6.

CH-16

809 10.2 Table 6 ge Similar to above Keep it simple.Put this table in IEC 61850-8-1. Just refer to 62351-4 from IEC 61850-8-1.61850-8-1 says what is mandatory, what is optional (one place for all the PICs).IEC 62351-4 says how it shall be implemented.

62351-4 is changing and the PICs should be in -6.

The decision of WG15 and WG10 was to put this table into -6.

CH-17

806 10.2 Table 6 ge IEC 61850-8-1 also has a PICs (Table 121). How should Table 6 be interpreted in conjunction with IEC 61850-8-1 Table 121?

In the end, ACSI and End-to-End security shall be optional, and TLS mandatory.

Updated PICs table per WG15 which addresses the comment partially.

CH-18

809 10.2 Table 6 ge Separate “Application Layer Security” from “Transport Layer Security”. Application Layer Security shall be optional, Transport Layer Security shall be mandatory.

ACSE Authentication shall be “o”. Disagree, It must be mandatory for backward compatibility.

CH-19

809 10.2 Table 6 ge “Configurability” row is unnecessary. Table 2 already lists combinations.It goes without saying, that if we have many combinations, then it will be configurable.

delete “configurability” row. Agree

CH-20

809 10.2 Table 6 ge CS811 Ambiguous reference to IEC 62351-4. (preferred) IEC 61850-8-1 should reference IEC 62351-4 directly, for MMS 8-1 “Application Profile

Corrected.

Page 21 of 29

MB/NC




Type of comment


Be consistent with the usage. Pick one of these terms and use it consistently throughout all standards: “ACSE Authentication”“A-security profile” “Application profile security”Another reason why we should not “chain” standards together.

Security”.(less preferred) correct all standards to use the same term.

CH-21

809 10.2 Table 6 ge ACSE Authentication should be optional, and TLS mandatory. It seems that both ACSE and TLS (1.2) are mandatory in the current wording.

ACSE Authentication shall be optional. Disagree for backward compatibility reasons.

DE-05

809 10.2 Table 6 caption

ed To better distinguish the PICS tables, it would be good to make the relation with application level security or at least security above TLS clear.

Please change the caption of the table 6 to “PICS for application security IEC 61850-8-1 Client/Server”.

Agree.

8-2 is not included since it is not officially ISO 9506.

DE-06

809 10.2 Table 6, item CS811

te Reference to wrong clause 11.1 (should be 11 for normative part of A-profile)

Please change the reference to 11 to cover the whole A-profile.

Will need to get the correct document and reference.

DE-07

809 10.2 Table 6, item CS811

te For backward compatibility, support of ACSE authentication is required, for new systems this should be optional. IEC 62351-4 calls this application A-profile “compatibility usage”

Please make the unrestricted mandatory support of the ACSE authentication optional. Alternatively make clear that the mandatory support is only intended for backward compatibility and that TLS application is considered sufficient.

Disagree, It is not conditional

Disagree that TLS only is sufficient for RBAC..

DE-08

809 10.2 Table 6, item CS812

te Reference to wrong clause 12 (should be 13 for normative part of e2e). Section 12 only provides an overview of the end-to-end security approach

Please change the reference to 13 to reference the normative part of the end-to-end security definition.

Will need to get the correct document and reference.

DE-09

809 10.2 Table 6, item CS812

te The reference to the T-Profile security is missing in this table. See also comment above to the combination of A-profile and T-profile. Potential changes should be reflected here as well.

Please make the changes accordingly with comment DE03.

See DE-03.

CH-22

815 10.2.1 Table 7 ge Similar to above Keep it simple.Put this table in IEC 61850-8-1, and then we don’t need IEC 62351-6 at all. Just refer to 62351-3 from IEC 61850-8-1.61850-8-1 says what is mandatory, what is optional (one place for all the PICs).IEC 62351-3 says how it shall be implemented.

Disagree.

Not per agreement between WG10 editors.

CH-23

815 10.2.1 Table 7 ge IEC 62351 clause 6.3.4.3Which part of IEC 62351?

Change to IEC 62351-3??? Agreed. Added reference to document and clause.

Page 22 of 29

MB/NC




Type of comment


DE-10

838 10.4 Table 11, item SG02

ed SG02 should read SGO2?Missing IEC before 62351-6

Please clarify the references. Agree,

DE-11

840 10.4 Table 12, item SGR2

ed Missing IEC before 62351-6 Please clarify the references. Agree

DE-12

840 10.5 Table 14, item SV22


DE-13

840 10.5 Table 15, item SVR1


SE34 857 10.6 Te SNTP1: RFC 5905 is Optional for both Clients and Servers. What is then the requirement on an implementation that is claiming conformance if the entire table is Optional?

Please clarify Tables have been re-arranged. If G4 is not declared, then the table does not apply. SNTP is the mandatory Time synce protocol in 8-1.

SE35 857 10.6 Te SNTP1: RFC 5905 is Optional for both Clients and Servers. What is then the requirement on an implementation that is claiming conformance if the entire table is Optional?

Please clarify Tables have been re-arranged. If G4 is not declared, then the table does not apply. SNTP is the mandatory Time synce protocol in 8-1.

DK 674-685 8.2.3.1 & 8.2.3.1

ed Although client and subscriber seems to synonymous, they should be intermix

Replace:clientwithsubscriber

Agree

Page 23 of 29

Annex of CA.doc

IEC62351-6 Ed1 CDV comments

Annex CA-A1

Issues and solution regarding SMV and GOOSE security replay protection

First, here is the current text from latest IEC62351-6 CDV regarding SMV replay protection:

6.2.2.1 Publisher

5.2.3.4.1 Server processing

To prevent SV replay, the Security field of the SV protocol shall be present (see Table 3).

ASN.1 Basic Encoding Rules (BER)SavPdu::= SEQUENCE {noASDU [0] IMPLICIT INTEGER (1..65535),security [1] ANY OPTIONAL,asdu [2] IMPLICIT SEQUENCE OF ASDU}

Table 1 – Extract from IEC 61850-9-2 (informative)

Prevention of replay requires that publisher include the optional security field in the SavPdu and implements a form of integrity protection as specified for the different T-Profiles (e.g. Layer 2 or Routable).

The SavPdu Security field shall not be present if Sampled Value security is not being provided on a given message. If security is being utilized for the message, the field shall be present, and its contents shall be:

IMPORT

security::= [0] IMPLICIT SEQUENCE { timestamp [0] IMPLICIT OCTETSTRING, --time of send }

&timestamp

The timestamp attribute shall represent the approximate time at which the SMV frame was formatted.

The octet format shall be per IEC 61850-8-1 for Timestamp

The time accuracy of the value shall be at least 250 usec.

The issue:

The timestamp is based on current time which can be synchronized, unsynchronized or even unavailable in some case on some merging units. The fact that a resynchronization may occurs imply that the time may step back in time; this makes the replay protection tricky and complex.

Proposed solution:

In order to avoid complex handling of a timestamp that may jump in the past, we should use a linear counter in order to simplify the replay protection scheme. Here is the new proposal:

IMPORT

security::= [0] IMPLICIT SEQUENCE { timestamp [0] IMPLICIT INTEGER, --time of send reference (unsigned 32bits integer Second of day)

sequence_num [1] IMPLICIT INTEGER, --unsigned 32bits integer }

&timestamp

The timestamp attribute shall represent:

the approximate time at which the first SMV frame was formatted

OR

when the sequence_num value wrap to 0.

The timestamp format shall be the integer part represented in the first 4 bytes of an IEC 61850-8-1 Timestamp

& sequence_num

The sequence_num attribute shall be initialized to 0 when the first SMV frame is sent. It shall be incremented by 1 for each subsequent frame. When the value exceeds the maximum value of an unsigned 32bits integer, it shall wrap to 0 and the timestamp field shall be updated.

Using a linear counter makes replay protection quite simple. Also, using the time reference make it easy to wrap the value and also to handle device restarts.

This replay protection scheme can easily be applied to GOOSE also. In order to do that, the same security extension can be included in the GOOSE APDU from IEC61850-8-1:

IECGoosePdu ::= SEQUENCE {

gocbRef [0] IMPLICIT VISIBLE-STRING,

timeAllowedtoLive [1] IMPLICIT INTEGER,

datSet [2] IMPLICIT VISIBLE-STRING,

goID [3] IMPLICIT VISIBLE-STRING OPTIONAL,

T [4] IMPLICIT UtcTime,

stNum [5] IMPLICIT INTEGER,

sqNum [6] IMPLICIT INTEGER,

simulation [7] IMPLICIT BOOLEAN DEFAULT FALSE,

confRev [8] IMPLICIT INTEGER,

ndsCom [9] IMPLICIT BOOLEAN DEFAULT FALSE,

numDatSetEntries [10] IMPLICIT INTEGER,

allData [11] IMPLICIT SEQUENCE OF Data,

security [12] ANY OPTIONAL,

}