idnits 2.17.1 draft-weis-gdoi-iec62351-9-04.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 (May 16, 2014) is 3623 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' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 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: November 17, 2014 H. Falk 6 SISCO 7 May 16, 2014 9 GDOI Protocol Support for IEC 62351 Security Services 10 draft-weis-gdoi-iec62351-9-04 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 November 17, 2014. 39 Copyright Notice 41 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4 61 2. IEC 61850 Protocol Information . . . . . . . . . . . . . . . . 5 62 2.1. ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. KD Payload . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 16 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 76 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 . . 19 78 Appendix B. Implementation Considerations . . . . . . . . . . . . 22 79 B.1. DER Length Fields . . . . . . . . . . . . . . . . . . . . 22 80 B.2. Groups with Multiple Senders . . . . . . . . . . . . . . . 22 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 84 1. Introduction 86 Power substations use Generic Object Oriented Substation Events 87 (GOOSE) protocol [IEC-61850-8-1] to distribute control information to 88 groups of devices using a multicast strategy. Sources within the 89 power substations also distribute IEC 61850-9-2 sampled values data 90 streams [IEC-61850-9-2]. The IEC 62351-9 standard [IEC-62351-9] 91 describes key management methods for the security methods protecting 92 these IEC 61850 messages, including methods of device authentication 93 and authorization, and methods of policy and keying material 94 agreement for IEC 61850 message encryption and data integrity 95 protection. These key management methods include the use of GDOI 96 [RFC6407] to distribute the security policy and session keying 97 material used to protect IEC 61850 messages when the messages are 98 sent to a group of devices. 100 The protection of the messages is defined within IEC 62351-6 101 [IEC-62351-6], IEC 61850-8-1 [IEC-61850-8-1], and IEC 61850-9-2 102 [IEC-61850-9-2]. Protected IEC 61850 messages typically include the 103 output of a Message Authentication Code (MAC) and may also be 104 encrypted using a symmetric cipher such as the Advanced Encryption 105 Standard (AES). 107 Section 5.5.2 of RFC 6407 specifies that the following information 108 needs to be provided in order to fully define a new Security 109 Protocol: 111 o The Protocol-ID for the particular Security Protocol. 113 o The SPI Size 115 o The method of SPI generation 117 o The transforms, attributes, and keys needed by the Security 118 Protocol. 120 This document defines GDOI payloads to distribute policy and keying 121 material to protect IEC 61850 messages, and defines the necessary 122 information to ensure interoperability between IEC 61850 123 implementations. 125 1.1. Requirements notation 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 1.2. Terminology 133 The following key terms are used throughout this document: 135 Generic Object Oriented Substation Events Power substation control 136 model defined as per IEC 61850. 138 IEC 61850 message A message in the IEC 61850 family of protocols 139 carrying control or data between Substation devices. 141 1.3. Acronyms and Abbreviations 143 The following acronyms and abbreviations are used throughout this 144 document 146 AES Advanced Encryption Standard 148 CK Current Key 150 GCKS Group Controller/Key Server 152 GDOI Group Domain of Interpretation 154 GM Group Member 156 GOOSE Generic Object Oriented Substation Events 158 KD Key Download 160 KEK Key Encryption Key 162 MAC Message Authentication Code 164 NK Next Key 166 SA Security Association 168 SPI Security Parameter Index 170 TEK Traffic Encryption Key 172 2. IEC 61850 Protocol Information 174 The following sections describe the GDOI payload extensions that are 175 needed in order to distribute security policy and keying material for 176 the IEC 62351 Security Services. The Identification (ID) Payload is 177 used to describe an IEC 62351 GDOI group. The Security Association 178 (SA) Traffic Encryption Key (TEK) payload is used to describe the 179 policy defined by a Group Controller/Key Server (GCKS) for a 180 particular IEC 62351 traffic selector. No changes are required to 181 the Key Download (KD) Payload, but a mapping of IEC 62351 keys to KD 182 Payload key types is included. 184 2.1. ID Payload 186 The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group 187 Member (GM) to declare the group it would like to join. A group is 188 defined by an ID payload as defined in GDOI [RFC6407] and reproduced 189 in Figure 1. 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 194 ! Next Payload ! RESERVED ! Payload Length ! 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 196 ! ID Type ! DOI-Specific ID Data = 0 ! 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 198 ~ Identification Data ~ 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 201 Figure 1: RFC 6407 Identification Payload 203 An ID Type name of ID_OID (value 13) is defined in this memo to 204 specify an Object Identifier (OID) [ITU-T-X.683] encoded using 205 Distinguished Encoding Rules (DER) [ITU-T-X.690]. Associated with 206 the OID may be an OID Specific Payload DER encoded as further 207 defining the group. Several OIDs are specified in [IEC-62351-9] for 208 use with IEC 61850. Each OID represents a GOOSE or Sampled Value 209 protocol, and in some cases IEC 61850 also specifies a particular 210 multicast destination address to be described in the OID Specific 211 Payload field. The format of the ID_OID Identification Data is 212 specified as shown in Figure 2. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 217 ! OID Length ! OID ~ 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 219 ! OID Specific Payload Length ! OID Specific Payload ~ 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 222 Figure 2: ID_OID Identification Data 224 The ID_OID Identification Data fields are defined as follows: 226 o OID Length (1 octet) -- Length of the OID field. 228 o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER 229 [ITU-T-X.690]. 231 o OID Specific Payload Length (2 octets) -- Length of the OID 232 Specific Payload. Set to zero if the OID does not require an OID 233 Specific Payload. 235 o OID Specific Payload (variable) -- OID specific selector encoded 236 in DER. If OID Specific Payload Length is set to zero this field 237 does not appear in the ID payload. 239 2.2. SA TEK Payload 241 The SA TEK payload contains security attributes for a single set of 242 policy associated with a group TEK. The type of policy to be used 243 with the TEK is described by a Protocol-ID field included in the SA 244 TEK. As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID 245 describes a particular TEK Protocol-Specific Payload definition. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 250 ! Next Payload ! RESERVED ! Payload Length ! 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 252 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 253 +-+-+-+-+-+-+-+-+ ~ 254 ~ ~ 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 257 Figure 3: RFC 6407 SA TEK Payload 259 The Protocol-ID name of GDOI_PROTO_IEC_61850 (value TBD1) is defined 260 in this memo for the purposes of distributing IEC 61850 policy. A 261 GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID 262 Specific Payload that together define the selectors for the network 263 traffic. The selector fields are followed by security policy fields 264 indicating how the specified traffic is to be protected. The 265 GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as 266 shown in Figure 4. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 271 ! OID Length ! OID ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 273 ! OID Specific Payload Length ! OID Specific Payload ~ 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 275 ! Current KeyID ! RESERVED ! CK Remaining Lifetime Value ! 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 277 ! CK Auth Alg ! CK Key Alg ! 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 279 ! Next KeyID ! RESERVED ! NK Remaining Lifetime Value ! 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 281 ! NK Auth Alg ! NK Key Alg ! 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 284 Figure 4: IEC-61850 SA TEK Payload 286 The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as 287 follows: 289 o OID Length (1 octet) -- Length of the OID field. 291 o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER. 292 OIDs defined in IEC 61850 declare the type of IEC 61850 message to 293 be protected, as defined by [IEC-62351-9]. 295 o OID Specific Payload Length (2 octets) -- Length of the OID 296 Specific Payload. This field is set to zero if the policy does 297 not include an OID Specific Payload. 299 o OID Specific Payload (variable) -- The traffic selector (e.g., 300 multicast address) specific to the OID encoded using DER. Some 301 OID policy settings do not require the use of an OID Specific 302 Payload, in which case this field is not included in the TEK and 303 the OID Specific Payload Length is set to zero. 305 o Current KeyID (1 octet) -- Identifier for the Current Key. This 306 field represents a SPI. 308 o RESERVED (1 octet) -- MUST be zero, and MUST be ignored on 309 receipt. 311 o CK Remaining Lifetime value (2 octets) -- The number of minutes 312 prior to the next scheduled Current Key change. A value of zero 313 (0) shall indicate that no key change has been scheduled. 315 o CK Auth Alg (2 octets) -- Current Key Authentication Algorithm ID. 316 Valid values are define in Section 2.2.2. 318 o CK Key Alg (2 octets) -- Current Key Confidentiality Algorithm ID. 319 Valid values are define in Section 2.2.3. 321 o Next KeyID (1 octet) -- Identifier for the Next Key. This field 322 represents a SPI. 324 o RESERVED (1 octet) -- MUST be zero, and MUST be ignored on 325 receipt. 327 o NK Remaining Lifetime value (2 octets) -- The number of minutes 328 prior to the next scheduled Next Key change. A value of zero (0) 329 shall indicate that no key change has been scheduled. 331 o NK Auth Alg (2 octets) -- Next Key Authentication Algorithm ID. 332 Valid values are define in Section 2.2.2. 334 o NK Key Alg (2 octets) -- Next Key Confidentiality Algorithm ID. 335 Valid values are define in Section 2.2.3. 337 An implementation can reasonably expect the NK Remaining Lifetime 338 value to be a larger value than the CK Remaining Lifetime; that is, 339 if it is to be the NK, then it's lifetime is expected to be longer. 340 If, however, the NK Remaining Lifetime expires before the CK 341 Remaining Lifetime then the NK is of no effect and the GM will not 342 use the NK. If a GM discovers that the CK is near the end of its 343 lifetime and it has no NK (e.g., the NK lifetime has already 344 expired), the GM is expected to register with the GCKS in order to 345 obtain newer key and policy updates. 347 2.2.1. Selectors 349 The OID and (optionally) an OID Specific Payload that together define 350 the selectors for the network traffic. While they may match the OID 351 and OID Specific Payload that the GM had previously requested in the 352 ID payload, there is no guarantee that this will be the case. 353 Including selectors in the SA TEK is important for at least the 354 following reasons: 356 o The KS policy may direct the KS to return multiple TEKs, each 357 representing different traffic selectors and it is important that 358 every GM receiving the set of TEKs explicitly identify the traffic 359 selectors associated with the TEK. 361 o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, 362 which distributes new or replacement TEKs to group members. Since 363 the GROUPKEY-PUSH message does not contain an ID payload the TEK 364 definition must include the traffic selectors. 366 2.2.2. Authentication Algorithms 368 This memo defines the following Authentication Algorithms for use 369 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5]. 371 o HMAC-SHA256-128. Specifies the use of SHA-256 [FIPS180-3.2008] 372 combined with HMAC [RFC2104]. The output is truncated to 128 373 bits, as per [RFC2104]. The key size is the size of the hash 374 value produced by SHA-256 (256 bits). 376 o HMAC-SHA256. Specifies the use of SHA-256 [FIPS180-3.2008] 377 combined with HMAC [RFC2104]. The key size is the size of the 378 hash value produced by SHA-256 (256 bits). 380 2.2.3. Confidentiality Algorithms 382 This memo defines the following Confidentiality Algorithms for use 383 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5]. 385 o NONE. Specifies that no Confidentiality Algorithm is to used. 387 o AES-CBC-128. Specifies the use of AES [FIPS197] in the Cipher 388 Block Chaining (CBC) mode [SP.800-38A] with a 128 bit key size. 390 o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher 391 Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. 393 2.2.4. SPI Discussion 395 As noted in Section 1, RFC 6407 requires that characteristics of a 396 SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is 397 represented as a Key Identifier (KeyID). It's size is 1 octet. The 398 KeyID is unilaterally chosen by the GCKS using any method chosen by 399 the implementation. However, an implementation needs to take care 400 not to duplicate a KeyID value that is currently in use for a 401 particular group. 403 2.3. KD Payload 405 The KD Payload contains group keys for the policy specified in the SA 406 Payload. It is comprised of a set of Key Packets, each of which hold 407 the keying material associated with a SPI (i.e., an IEC 61850 Key 408 Identifier). The RFC 6407 KD payload format is reproduced in 409 Figure 5. 411 0 1 2 3 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 414 ! Next Payload ! RESERVED ! Payload Length ! 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 416 ! Number of Key Packets ! RESERVED2 ! 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 418 ~ Key Packets ~ 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 421 Figure 5: KD Payload 423 Each Key Packet holds the keying material associated with a 424 particular IEC 61850 Key Identifier, although GDOI refers to it as a 425 SPI. The keying material is described in a set of attributes 426 indicating an encryption key, integrity key, etc., in accordance with 427 the security policy of the group as defined by the associated SA 428 Payload. Each Key Packet has the following format, reproduced in 429 Figure 6. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 434 ! KD Type ! RESERVED ! Key Packet Length ! 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 436 ! SPI Size ! SPI (variable) ~ 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 438 ~ Key Packet Attributes ~ 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 441 Figure 6: Key Packet 443 No changes are needed to GDOI in order to distribute IEC 61850 keying 444 material, but the keys MUST be distributed as defined in Section 5.6 445 of RFC 6407. The KD Type MUST be TEK (1). A key associated with an 446 IEC 61850 Authentication Algorithm (distributed in the CK Auth Alg 447 and NK Auth Alg SA TEK fields) MUST be distributed as a 448 TEK_INTEGRITY_KEY attribute, and a key associated with an IEC 61850 449 Confidentiality Algorithm (distributed in the CK Key Alg and NK Key 450 Alg SA TEK fields) MUST be distributed as a TEK_ALGORITHM_KEY 451 attribute. 453 3. Security Considerations 455 GDOI is a security association (SA) management protocol for groups of 456 senders and receivers. This protocol performs authentication of 457 communicating protocol participants (Group Member, Group Controller/ 458 Key Server). GDOI provides confidentiality of key management 459 messages, and it provides source authentication of those messages. 460 GDOI includes defenses against man-in-middle, connection hijacking, 461 replay, reflection, and denial-of-service (DOS) attacks on unsecured 462 networks. GDOI assumes the network is not secure and may be under 463 the complete control of an attacker. The Security Considerations 464 described in RFC 6407 are relevant to the distribution of GOOSE and 465 sampled values policy as defined in this memo. 467 Message Authentication is a mandatory property for IEC 62351 Security 468 Services. A common practice is to truncate the output of a MAC and 469 include part of the bits in the integrity protection field of the 470 data security transform. Current guidance in [RFC2104] is to 471 truncate no less than half of the length of the hash output. The 472 authentication algorithm HMAC-SHA256-128 defined in this memo 473 truncates the output to exactly half of the output, which follows 474 this guidance. 476 Confidentiality is an optional security property for IEC 62351 477 Security Services. Confidentiality Algorithm IDs SHOULD be included 478 in the IEC-61850 SA TEK Payload if the IEC 61850 messages are 479 expected to traverse public network links and not protected by 480 another level of encryption (e.g., an encrypted Virtual Private 481 Network). Current cryptographic advice indicates that the use of 482 AES-CBC-128 for confidentiality is sufficient for the foreseeable 483 future [SP.800-131], but some security policies may require the use 484 of AES-CBC-256. 486 4. IANA Considerations 488 The following additions are made to the GDOI payloads registry 489 [GDOI-REG]. 491 A new SA TEK Payload Values - Protocol-ID value is defined. Its type 492 is GDOI_PROTO_IEC_61850, with a value of TBD1. 494 A new registry is added defining Auth Alg values. The Attribute 495 Class is called "IEC62351-9 Authentication Values". The terms 496 Specification Required and Private Use are to be applied as defined 497 in [RFC5226]. 499 Name Value 500 ---- ----- 501 Reserved 0 502 HMAC-SHA256-128 1 503 HMAC-SHA256 2 504 Specification Required 3-61439 505 Private Use 61440-65535 507 A new registry is added defining Key Alg values. The Attribute Class 508 is called "IEC62351-9 Confidentiality Values". The terms 509 Specification Required and Private Use are to be applied as defined 510 in [RFC5226]. 512 Name Value 513 ---- ----- 514 Reserved 0 515 NONE 1 516 AES-CBC-128 2 517 AES-CBC-256 3 518 Specification Required 4-61439 519 Private Use 61440-65535 521 A new registry for ID Types is defined for the Identification Payload 522 when the DOI is GDOI. The registry is taken from the ID Types 523 registry for the IPsec DOI, which were previously assumed. Values 524 1-12 are defined identically to the equivalent values in the IPsec 525 DOI. Value 13 is defined in this memo. The terms Specification 526 Required and Private Use are to be applied as defined in [RFC5226]. 528 Name Value 529 ---- ----- 530 Reserved 0 531 ID_IPV4_ADDR 1 532 ID_FQDN 2 533 ID_USER_FQDN 3 534 ID_IPV4_ADDR_SUBNET 4 535 ID_IPV6_ADDR 5 536 ID_IPV6_ADDR_SUBNET 6 537 ID_IPV4_ADDR_RANGE 7 538 ID_IPV6_ADDR_RANGE 8 539 ID_DER_ASN1_DN 9 540 ID_DER_ASN1_GN 10 541 ID_KEY_ID 11 542 ID_LIST 12 543 ID_OID 13 544 Specification Required 14-61439 545 Private Use 61440-65535 547 5. Acknowledgements 549 The authors thanks Sean Turner, Steffen Fries, Yoav Nir, and Vincent 550 Roca for their thoughtful reviews, each of which resulted in 551 substantial improvements to the memo. 553 6. References 555 6.1. Normative References 557 [IEC-62351-9] 558 International Electrotechnical Commission, "IEC 62351 Part 559 9 - Key Management", IEC 62351-9 , January 2013. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 565 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 566 May 2008. 568 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 569 of Interpretation", RFC 6407, October 2011. 571 6.2. Informative References 573 [FIPS180-3.2008] 574 National Institute of Standards and Technology, "Secure 575 Hash Standard", FIPS PUB 180-3, October 2008, . 579 [FIPS197] "Advanced Encryption Standard (AES)", United States of 580 America, National Institute of Science and 581 Technology, Federal Information Processing Standard (FIPS) 582 197, November 2001. 584 [GDOI-REG] 585 Internet Assigned Numbers Authority, "Group Domain of 586 Interpretation (GDOI) Payload Type Values", IANA Registry, 587 December 2004, . 590 [IEC-61850-8-1] 591 International Electrotechnical Commission, "Specific 592 Communication networks and systems for power utility 593 automation - Part 8-1: Specific communication service 594 mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 595 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. 597 [IEC-61850-9-2] 598 International Electrotechnical Commission, "Communication 599 networks and systems for power utility automation - Part 600 9-2: Specific communication service mapping (SCSM) - 601 Sampled values over ISO/IEC 8802-3", IEC-61850-2 , 602 September 2011. 604 [IEC-62351-6] 605 International Electrotechnical Commission, "Power systems 606 management and associated information exchange - Data and 607 communications security - Part 6: Security for IEC 61850", 608 IEC-62351-6 , June 2007. 610 [IEC-TR-61850-90-5] 611 International Electrotechnical Commission, "Communication 612 networks and systems for power utility automation - Part 613 90-5: Use of IEC 61850 to transmit synchrophasor 614 information according to IEEE C37.118", IEC 62351-9 , 615 May 2012. 617 [ITU-T-X.683] 618 "Information technology - Abstract Syntax Notation One 619 (ASN.1): Parameterization of ASN.1 specifications", SERIES 620 X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI 621 networking and system aspects - Abstract Syntax Notation 622 One (ASN.1) , July 2002, . 625 [ITU-T-X.690] 626 "Information technology-ASN.1 encoding rules: 627 Specification of Basic Encoding Rules (BER), Canonical 628 Encoding Rules (CER) and Distinguished Encoding Rules 629 (DER)", SERIES X: DATA NETWORKS, OPEN SYSTEM 630 COMMUNICATIONS AND SECURITY OSI networking and 631 system aspects - Abstract Syntax Notation One 632 (ASN.1) , 2008, 633 . 635 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 636 Hashing for Message Authentication", RFC 2104, 637 February 1997. 639 [SP.800-131] 640 Barker, E. and A. Roginsky, "Recommendation for the 641 Transitioning of Cryptographic Algorithms and Key 642 Lengths", United States of America, National Institute of 643 Science and Technology DRAFT NIST Special Publication 800- 644 131, June 2010. 646 [SP.800-38A] 647 Dworkin, M., "Recommendation for Block Cipher Modes of 648 Operation", United States of America, National Institute 649 of Science and Technology, NIST Special Publication 800- 650 38A 2001 Edition, December 2001. 652 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 654 An IED begins a GROUPKEY-PULL exchange and requests keys and security 655 policy for 61850_UDP_ADDR_GOOSE (OID = 1.2.840.10070.61850.8.1.2 as 656 defined in [IEC-61850-9-2]) and IP multicast address 233.252.0.1 657 encoded as specified in [IEC-61850-9-2]. 659 OID and OID Specific Payload protocol fields are variable length 660 fields. To improve readability, their representations in Figure 7 661 and Figure 8 are "compressed" in the figure, as indicated by a 662 trailing "~" for these fields. Implementations should be aware that 663 because these fields are variably sized, some payload fields may not 664 be conveniently aligned on an even octet. 666 Note 2: The actual DER for the OID Specific Payload field is defined 667 in [IEC-62351-6]. 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 672 ! Next Payload ! RESERVED ! Payload Length ! 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 674 ! ID Type=13 ! DOI-Specific ID Data = 0 ! 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 676 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 678 ! OID Specific Payload Len ! OID SP= ~ 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 681 Figure 7: Sample Identification Payload 683 The Key Server responds with the following SA TEK payload including a 684 single GDOI_PROTO_IEC_61850 Protocol-Specific TEK payload in the 685 second GROUPKEY-PULL message. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 690 ! Next Payload ! RESERVED ! Payload Length ! 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 692 ! DOI = 2 ! 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 694 ! Situation = 0 ! 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 696 ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 698 ! Prot-ID=TBD1 ! 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 700 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 702 ! OID Specific Payload Len !OID SP= ~ 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 704 ! Cur KeyID=1 ! RESERVED ! CK Remaining Lifetime=0x3600 ! 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 706 ! CK AuthAlg=1 (HMAC-SHA256-128)! CK Key Alg=2 (AES-CBC-128) ! 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 708 ! Next KeyID=2 ! RESERVED ! NK Remaining Lifetime=0xffff ! 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 710 ! CK AuthAlg=2 (HMAC-SHA256) ! CK Key Alg=1 (NONE) ! 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 713 Figure 8: Sample IEC-61850 SA Payload 715 The IED acknowledges that it is capable and willing to use this 716 policy in the third GROUPKEY-PULL message. In response the KS sends 717 a KD payload to the requesting IED. This concludes the GROUPKEY-PULL 718 exchange. 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 723 ! Next Payload ! RESERVED ! Payload Length ! 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 725 ! Number of Key Packets=2 ! RESERVED2 ! 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 727 ! KD Type=1 ! RESERVED ! Key Packet Length=62 ! 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 729 ! SPI Size=1 ! SPI=1 ! 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 731 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 733 ! ! 734 ! ! 735 ! ! 736 ! HMAC-SHA256 Key ! 737 ! ! 738 ! ! 739 ! ! 740 ! ! 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 742 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 744 ! ! 745 ! AES-CBC-128 Key ! 746 ! ! 747 ! ! 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 749 ! KD Type=1 ! RESERVED ! Key Packet Length=42 ! 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 751 ! SPI Size=1 ! SPI=2 ! 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 753 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 755 ! ! 756 ! ! 757 ! ! 758 ! HMAC-SHA256 Key ! 759 ! ! 760 ! ! 761 ! ! 762 ! ! 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 765 Figure 9: Sample KD Payload 767 Appendix B. Implementation Considerations 769 Several topics have been suggested as useful for implementors. 771 B.1. DER Length Fields 773 The ID and SA TEK payloads defined in this memo include explicit 774 lengths for fields formatted as DER. This includes the OID Length 775 and OID Specific Payload Length fields shown in Figure 2 and 776 Figure 4. Strictly speaking, these lengths are redundant since the 777 length of the DER value is also encoded within the DER fields. It 778 would be possible to determine the lengths of the fields from those 779 encoded values. However, many implementations will find the explicit 780 length fields convenient when constructing and sanity checking the 781 GDOI messages including these payloads. Implementations will thus be 782 spared from manipulating the DER itself when performing activities 783 that do not otherwise require parsing in order to obtain values 784 therein. 786 B.2. Groups with Multiple Senders 788 GCKS policy may specify more than one protected type of IEC 61850 789 message within a GDOI group. This is represented within a GDOI SA 790 Payload by the presence of an SA TEK Payload for each multicast group 791 that is protected as part of group policy. The OID contained in each 792 of the SA TEK Payloads may be identical, but the value of each OID 793 Specific Payload would be unique. 795 Authors' Addresses 797 Brian Weis 798 Cisco Systems 799 170 W. Tasman Drive 800 San Jose, California 95134-1706 801 USA 803 Phone: +1 408 526 4796 804 Email: bew@cisco.com 806 Maik Seewald 807 Cisco Systems 808 Am Soeldnermoos 17 809 D-85399 Hallbergmoos, 810 Germany 812 Phone: +49 619 6773 9655 813 Email: maseewal@cisco.com 815 Herb Falk 816 SISCO 817 6605 19-1/2 Mile Road 818 Sterling Heights, MI 48314 819 USA 821 Phone: +1 586 254 0020 x105 822 Email: herb@sisconet.com