idnits 2.17.1 draft-weis-gdoi-iec62351-9-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2013) is 3919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC-62351-9' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC-TR-61850-90-5' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Weis 3 Internet-Draft M. Seewald 4 Intended status: Standards Track Cisco Systems 5 Expires: February 3, 2014 H. Falk 6 SISCO 7 August 2, 2013 9 IEC 62351 Security Protocol support for GDOI 10 draft-weis-gdoi-iec62351-9-02 12 Abstract 14 The IEC 61850 power utility automation family of standards describe 15 methods using Ethernet and IP for distributing control and data 16 frames within and between substations. The IEC 61850-90-5 and IEC 17 62351-9 standards specify the use of the Group Domain of 18 Interpretation (GDOI) protocol (RFC 6407) to distribute security 19 transforms for some IEC 61850 security protocols. This memo defines 20 GDOI payloads to support those security protocols. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 3, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3 61 2. IEC 61850 Protocol Information . . . . . . . . . . . . . . . . 5 62 2.1. ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. Key Download Payload . . . . . . . . . . . . . . . . . . . 9 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 Power substations use Generic Object Oriented Substation Events 83 (GOOSE) protocol [IEC-61850-8-1] to distribute control information to 84 groups of devices using a multicast strategy. Sources within the 85 power substations also distribute IEC 61850-9-2 sampled values data 86 streams [IEC-61850-9-2]. The IEC 62351-9 standard [IEC-62351-9] has 87 specified the use of GDOI [RFC6407] to distribute security policy and 88 session keying material protecting these frames. 90 Section 5.5.2 of RFC 6407 specifies that the following information 91 needs to be provided in order to fully define a new Security 92 Protocol: 94 o The Protocol-ID for the particular Security Protocol. 96 o The SPI Size 98 o The method of SPI generation 100 o The transforms, attributes, and keys needed by the Security 101 Protocol. 103 This document defines GDOI payloads to distribute policy and keying 104 material for IEC 61850, and defines the necessary information to 105 ensure interoperability between IEC 61850 implementations. 107 1.1. Requirements notation 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 1.2. Terminology 115 The following key terms are used throughout this document: 117 Generic Object Oriented Substation Events Power substation control 118 model defined as per IEC 61850. 120 1.3. Acronyms and Abbreviations 122 The following acronyms and abbreviations are used throughout this 123 document 124 GCKS Group Controller/Key Server 126 GDOI Group Domain of Interpretation 128 GM Group Member 130 GOOSE Generic Object Oriented Substation Events 132 KD Key Download Payload 134 KEK Key Encryption Key 136 SA Security Association 138 SPI Security Parameter Index 140 TEK Traffic Encryption Key 142 2. IEC 61850 Protocol Information 144 2.1. ID Payload 146 The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group 147 Member (GM) to declare the group it would like to join. A group is 148 defined by an ID payload as defined in GDOI [RFC6407] and reproduced 149 in Figure 1. 151 0 1 2 3 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 154 ! Next Payload ! RESERVED ! Payload Length ! 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 156 ! ID Type ! DOI-Specific ID Data = 0 ! 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 158 ~ Identification Data ~ 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 161 Figure 1: RFC 6407 Identification Payload 163 An ID Type name of ID_OID (value 13) is defined in this memo to 164 specify an ASN.1 Object Identifier (OID) [ITU-T-X.683]. Associated 165 with the OID may be an OID Specific Payload further defining the 166 group. Several OIDs are specified in [IEC-62351-9] for use with IEC 167 61850. Each OID represents a GOOSE or Sampled Value protocol, and in 168 some cases IEC 61850 also specifies a particular multicast 169 destination address to be described in the OID Specific Payload 170 field. The format of the ID_OID Identification Data is specified as 171 shown in Figure 2. 173 0 1 2 3 174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 176 ! OID Length ! OID ~ 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 178 ! OID Specific Payload Length ! OID Specific Payload ~ 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 181 Figure 2: ID_OID Identification Data 183 The ID_OID Identification Data fields are defined as follows: 185 o OID Length (1 octet) -- Total length of the ASN.1 encoded OID. 187 o OID (variable) -- An ASN.1 encoded ObjectIdentifier using 188 Distinguished Encoding Rules (DER) [ITU-T-X.690]. 190 o OID Specific Payload Length (2 octets) -- Length of the OID 191 Specific Payload. Set to zero if the OID does not require an OID 192 Specific Payload. 194 o OID Specific Payload (variable) -- OID specific selector. If OID 195 Specific Payload Length is set to zero this field does not appear 196 in the ID payload. 198 2.2. SA TEK Payload 200 The SA TEK payload contains security attributes for a single set of 201 policy associated with a group TEK. The type of policy to be used 202 with the TEK is described by a Protocol-ID field included in the SA 203 TEK. As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID 204 describes a particular TEK Protocol-Specific Payload definition. 206 0 1 2 3 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 209 ! Next Payload ! RESERVED ! Payload Length ! 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 211 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 212 +-+-+-+-+-+-+-+-+ ~ 213 ~ ~ 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 216 Figure 3: RFC 6407 SA TEK Payload 218 The Protocol-ID name of GDOI_PROTO_IEC_61850 (value TBD1) is defined 219 in this memo for the purposes of distributing IEC 61850 policy. An 220 GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID 221 Specific Payload that together define the selectors for the network 222 traffic. The selector fields are followed by security policy fields 223 indicating how the specified traffic is to be protected. The 224 GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as 225 shown in Figure 4. 227 0 1 2 3 228 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 230 ! OID Length ! OID ~ 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 232 ! OID Specific Payload Length ! OID Specific Payload ~ 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 234 ! Current KeyID ! RESERVED ! CK Remaining Lifetime Value ! 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 236 ! CK Auth Alg ! CK Key Alg ! 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 238 ! Next KeyID ! RESERVED ! NK Remaining Lifetime Value ! 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 240 ! NK Auth Alg ! NK Key Alg ! 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 243 Figure 4: IEC-61850 SA TEK Payload 245 The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as 246 follows: 248 o OID Length (1 octet) -- Total length of the ASN.1 encoded OID. 250 o OID (variable) -- An ASN.1 encoded using Distinguished Encoding 251 Rules (DER) ObjectIdentifier. OIDs defined in IEC 61850 declare 252 the type of traffic to be encrypted. 254 o OID Specific Payload Length (2 octets) -- Length of the OID 255 Specific Payload. This field is set to zero if the policy does 256 not include an OID Specific Payload. 258 o OID Specific Payload (variable) -- The traffic selector (e.g., 259 multicast address) specific to the OID. Some OID policy settings 260 do not require the use of an OID Specific Payload, in which case 261 this field is not included in the TEK and the OID Specific Payload 262 Length is set to zero. 264 o Current KeyID (1 octet) -- Identifier for the Current Key. This 265 field represents a SPI. 267 o RESERVED (1 octet) -- MUST be zero, and MUST be ignored on 268 receipt. 270 o CK Remaining Lifetime value (2 octets) -- The number of minutes 271 prior to the next scheduled Current Key change. A value of zero 272 (0) shall indicate that no key change has been scheduled. 274 o CK Auth Alg (2 octets) -- Current Key Authentication Algorithm ID. 275 Valid values are define in Section 2.2.2. 277 o CK Key Alg (2 octets) -- Current Key Confidentiality Algorithm ID. 278 Valid values are define in Section 2.2.3. 280 o Next KeyID (1 octet) -- Identifier for the Next Key. This field 281 represents a SPI. 283 o RESERVED (1 octet) -- MUST be zero, and MUST be ignored on 284 receipt. 286 o NK Remaining Lifetime value (2 octets) -- The number of minutes 287 prior to the next scheduled Next Key change. A value of zero (0) 288 shall indicate that no key change has been scheduled. 290 o NK Auth Alg (2 octets) -- Next Key Authentication Algorithm ID. 291 Valid values are define in Section 2.2.2. 293 o NK Key Alg (2 octets) -- Next Key Confidentiality Algorithm ID. 294 Valid values are define in Section 2.2.3. 296 2.2.1. Selectors 298 The OID and (optionally) an OID Specific Payload that together define 299 the selectors for the network traffic. While they may match the OID 300 and OID Specific Payload that the GM had previously requested in the 301 ID payload, there is no guarantee that this will be the case. 302 Including selectors in the SA TEK is important for at least the 303 following reasons: 305 o The KS policy may direct the KS to return multiple TEKs, each 306 representing different traffic selectors and it is important that 307 every GM receiving the set of TEKs explicitly identify the traffic 308 selectors associated with the TEK. 310 o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, 311 which distributes new or replacement TEKs to group members. Since 312 the GROUPKEY-PUSH message does not contain an ID payload the TEK 313 definition must include the traffic selectors. 315 2.2.2. Authentication Algorithms 317 This memo defines the following Authentication Algorithms for use 318 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5]. 320 o HMAC-SHA256-80. Specifies the use of SHA-256 [FIPS180-3.2008] 321 combined with HMAC [RFC2104]. The output is truncated to 80 bits, 322 as per [RFC2104]. The key size is the size of the hash value 323 produced by SHA-256 (256 bits). 325 o HMAC-SHA256-128. Specifies the use of SHA-256 [FIPS180-3.2008] 326 combined with HMAC [RFC2104]. The output is truncated to 128 327 bits, as per [RFC2104]. The key size is the size of the hash 328 value produced by SHA-256 (256 bits). 330 o HMAC-SHA256. Specifies the use of SHA-256 [FIPS180-3.2008] 331 combined with HMAC [RFC2104]. The key size is the size of the 332 hash value produced by SHA-256 (256 bits). 334 2.2.3. Confidentiality Algorithms 336 This memo defines the following Confidentiality Algorithms for use 337 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5]. 339 o NONE. Specifies that no Confidentiality Algorithm is to used. 341 o AES-CBC-128. Specifies the use of AES [FIPS197] in the Cipher 342 Block Chaining (CBC) mode [SP.800-38A] with a 128 bit key size. 344 o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher 345 Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. 347 2.2.4. SPI Discussion 349 As noted in Section 1, RFC 6407 requires that characteristics of a 350 SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is 351 represented as a Key Identifier (KeyID). It's size is 1 octet. The 352 KeyID is unilaterally chosen by the GCKS using any method chosen by 353 the implementation. However, an implementation needs to take care 354 not to duplicate a KeyID value that is currently in use for a 355 particular group. 357 2.3. Key Download Payload 359 The Key Download Payload contains group keys for the policy specified 360 in the SA Payload. It is comprised of a set of Key Packets, each of 361 which hold the keying material associated with a SPI (i.e., an IEC 362 61850 Key Identifier). The RFC 6407 KD payload format is reproduced 363 in Figure 5. 365 0 1 2 3 366 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 368 ! Next Payload ! RESERVED ! Payload Length ! 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 370 ! Number of Key Packets ! RESERVED2 ! 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 372 ~ Key Packets ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 375 Figure 5: Key Download Payload 377 Each Key Packet holds the keying material associated with a 378 particular IEC 61850 Key Identifier, although GDOI refers to it as a 379 SPI. The keying material is described in a set of attributes 380 indicating an encryption key, integrity key, etc. based upon the 381 security policy of the group as defined by the associated SA Payload. 382 Each Key Packet has the following format, reproduced in Figure 6. 384 0 1 2 3 385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 387 ! KD Type ! RESERVED ! KD Length ! 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 389 ! SPI Size ! SPI (variable) ~ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 391 ~ Key Packet Attributes ~ 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 394 Figure 6: Key Packet 396 No changes are needed to GDOI in order to distribute IEC 61850 keying 397 material, but the keys MUST be distributed as defined in Section 5.6 398 of RFC 6407. The KD TYPE MUST be TEK (1). A key associated with an 399 IEC 61850 Authentication Algorithm (distributed in the CK Auth Alg 400 and NK Auth Alg SA TEK fields) MUST be distributed as a 401 TEK_INTEGRITY_KEY attribute, and a key associated with an IEC 61850 402 Confidentiality Algorithm (distributed in the CK Key Alg and NK Key 403 Alg SA TEK fields) MUST be distributed as a TEK_ALGORITHM_KEY 404 attribute. 406 3. Security Considerations 408 GDOI is a security association (SA) management protocol for groups of 409 senders and receivers. This protocol performs authentication of 410 communicating protocol participants (Group Member, Group Controller/ 411 Key Server). GDOI provides confidentiality of key management 412 messages, and it provides source authentication of those messages. 413 GDOI includes defenses against man-in-middle, connection hijacking, 414 replay, reflection, and denial-of-service (DOS) attacks on unsecured 415 networks. GDOI assumes the network is not secure and may be under 416 the complete control of an attacker. The Security Considerations 417 described in RFC 6407 are relevant to the distribution of GOOSE and 418 sampled values policy as defined in this memo. 420 4. IANA Considerations 422 The following additions are made to the GDOI payloads registry 423 [GDOI-REG]. 425 A new SA TEK Payload Values - Protocol-ID value is defined. Its type 426 is GDOI_PROTO_IEC_61850, with a value of TBD1. 428 A new registry is added defining Auth Alg values. The Attribute 429 Class is called "IEC62351-9 Authentication Values". The terms 430 Specification Required and Private Use are to be applied as defined 431 in [RFC5226]. 433 Name Value 434 ---- ----- 435 Reserved 0 436 HMAC-SHA256-80 1 437 HMAC-SHA256-128 2 438 HMAC-SHA256 3 439 Specification Required 4-61439 440 Private Use 61440-65535 442 A new registry is added defining Key Alg values. The Attribute Class 443 is called "IEC62351-9 Confidentiality Values". The terms 444 Specification Required and Private Use are to be applied as defined 445 in [RFC5226]. 447 Name Value 448 ---- ----- 449 Reserved 0 450 NONE 1 451 AES-CBC-128 2 452 AES-CBC-256 3 453 Specification Required 4-61439 454 Private Use 61440-65535 456 A new registry for ID Types is defined for the Identification Payload 457 when the DOI is GDOI. The registry is taken from the ID Types 458 registry for the IPsec DOI, which were previously assumed. Values 459 1-12 are defined identically to the equivalent values in the IPsec 460 DOI. Value 13 is defined in this memo. The terms Specification 461 Required and Private Use are to be applied as defined in [RFC5226]. 463 Name Value 464 ---- ----- 465 Reserved 0 466 ID_IPV4_ADDR 1 467 ID_FQDN 2 468 ID_USER_FQDN 3 469 ID_IPV4_ADDR_SUBNET 4 470 ID_IPV6_ADDR 5 471 ID_IPV6_ADDR_SUBNET 6 472 ID_IPV4_ADDR_RANGE 7 473 ID_IPV6_ADDR_RANGE 8 474 ID_DER_ASN1_DN 9 475 ID_DER_ASN1_GN 10 476 ID_KEY_ID 11 477 ID_LIST 12 478 ID_OID 13 479 Specification Required 14-61439 480 Private Use 61440-65535 482 5. Acknowledgements 484 The authors thanks Sean Turner for his careful review, which resulted 485 in several improvements to the memo. 487 6. References 489 6.1. Normative References 491 [IEC-62351-9] 492 International Electrotechnical Commission, "IEC 62351 Part 493 9 - Key Management", IEC 62351-9 , January 2013. 495 [IEC-TR-61850-90-5] 496 International Electrotechnical Commission, "Communication 497 networks and systems for power utility automation - Part 498 90-5: Use of IEC 61850 to transmit synchrophasor 499 information according to IEEE C37.118", IEC 62351-9 , 500 May 2012. 502 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 503 Requirement Levels", BCP 14, RFC 2119, March 1997. 505 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 506 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 507 May 2008. 509 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 510 of Interpretation", RFC 6407, October 2011. 512 6.2. Informative References 514 [FIPS180-3.2008] 515 National Institute of Standards and Technology, "Secure 516 Hash Standard", FIPS PUB 180-3, October 2008, . 520 [FIPS197] "Advanced Encryption Standard (AES)", United States of 521 America, National Institute of Science and 522 Technology, Federal Information Processing Standard (FIPS) 523 197, November 2001. 525 [GDOI-REG] 526 Internet Assigned Numbers Authority, "Group Domain of 527 Interpretation (GDOI) Payload Type Values", IANA Registry, 528 December 2004, . 531 [IEC-61850-8-1] 532 International Electrotechnical Commission, "Specific 533 Communication networks and systems for power utility 534 automation - Part 8-1: Specific communication service 535 mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 536 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. 538 [IEC-61850-9-2] 539 International Electrotechnical Commission, "Communication 540 networks and systems for power utility automation - Part 541 9-2: Specific communication service mapping (SCSM) - 542 Sampled values over ISO/IEC 8802-3", IEC-61850-2 , 543 September 2011. 545 [ITU-T-X.683] 546 "Information technology - Abstract Syntax Notation One 547 (ASN.1): Parameterization of ASN.1 specifications", SERIES 548 X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI 549 networking and system aspects - Abstract Syntax Notation 550 One (ASN.1) , July 2002, . 553 [ITU-T-X.690] 554 "Information technology-ASN.1 encoding rules: 555 Specification of Basic Encoding Rules (BER), Canonical 556 Encoding Rules (CER) and Distinguished Encoding Rules 557 (DER)", SERIES X: DATA NETWORKS, OPEN SYSTEM 558 COMMUNICATIONS AND SECURITY OSI networking and 559 system aspects - Abstract Syntax Notation One 560 (ASN.1) , 2008, 561 . 563 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 564 Hashing for Message Authentication", RFC 2104, 565 February 1997. 567 [SP.800-38A] 568 Dworkin, M., "Recommendation for Block Cipher Modes of 569 Operation", United States of America, National Institute 570 of Science and Technology, NIST Special Publication 800- 571 38A 2001 Edition, December 2001. 573 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 575 An IED begins a GROUPKEY-PULL exchange and requests keys and security 576 policy for 61850_UDP_ADDR_GOOSE (an OID defined in [IEC-61850-9-2]) 577 and IP multicast address 233.252.0.1. 579 0 1 2 3 580 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 582 ! Next Payload ! RESERVED ! Payload Length ! 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 584 ! ID Type=13 ! DOI-Specific ID Data = 0 ! 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 586 ! OID Len ! OID= ~ 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 588 ! OID Specific Payload Len !OID SP= ~ 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 591 Sample Identification Payload 593 The Key Server responds with the following SA TEK payload including a 594 single GDOI_PROTO_IEC_61850 Protocol-Specific TEK payload in the 595 second GROUPKEY-PULL message. 597 0 1 2 3 598 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 600 ! Next Payload ! RESERVED ! Payload Length ! 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 602 ! DOI = 2 ! 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 604 ! Situation = 0 ! 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 606 ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 608 ! Prot-ID=TBD1 ! 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 610 ! OID Len ! OID= ~ 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 612 ! OID Specific Payload Len !OID SP= ~ 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 614 ! Cur KeyID=1 ! RESERVED ! CK Remaining Lifetime=0x3600 ! 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 616 ! CK AuthAlg=1 (HMAC-SHA256-80) ! CK Key Alg=2 (AES-CBC-128) ! 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 618 ! Next KeyID=2 ! RESERVED ! NK Remaining Lifetime=0xffff ! 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 620 ! CK AuthAlg=2 (HMAC-SHA256-128)! CK Key Alg=1 (NONE) ! 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 623 Sample IEC-61850 SA Payload 625 The IED acknowledges that it is capable and willing to use this 626 policy in the third GROUPKEY-PULL message. In response the KS sends 627 a KD payload to the requesting IED. This concludes the GROUPKEY-PULL 628 exchange. 630 0 1 2 3 631 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 633 ! Next Payload ! RESERVED ! Payload Length ! 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 635 ! Number of Key Packets=2 ! RESERVED2 ! 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 637 ! KD Type=1 ! RESERVED ! KD Length=30 ! 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 639 ! SPI Size=1 ! SPI=1 ! 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 641 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 643 ! ! 644 ! ! 645 ! ! 646 ! HMAC-SHA256 Key ! 647 ! ! 648 ! ! 649 ! ! 650 ! ! 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 652 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 654 ! ! 655 ! AES-CBC-128 Key ! 656 ! ! 657 ! ! 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 659 ! KD Type=1 ! RESERVED ! KD Length=42 ! 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 661 ! SPI Size=1 ! SPI=2 ! 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 663 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 665 ! ! 666 ! ! 667 ! ! 668 ! HMAC-SHA256 Key ! 669 ! ! 670 ! ! 671 ! ! 672 ! ! 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 675 Sample Key Download Payload 677 Authors' Addresses 679 Brian Weis 680 Cisco Systems 681 170 W. Tasman Drive 682 San Jose, California 95134-1706 683 USA 685 Phone: +1 408 526 4796 686 Email: bew@cisco.com 688 Maik Seewald 689 Cisco Systems 690 Am Soeldnermoos 17 691 D-85399 Hallbergmoos, 692 Germany 694 Phone: +49 619 6773 9655 695 Email: maseewal@cisco.com 697 Herb Falk 698 SISCO 699 6605 19-1/2 Mile Road 700 Sterling Heights, MI 48314 701 USA 703 Phone: +1 586 254 0020 x105 704 Email: herb@sisconet.com