idnits 2.17.1 draft-weis-gdoi-iec62351-9-10.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 (October 28, 2016) is 2709 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: May 1, 2017 H. Falk 6 SISCO 7 October 28, 2016 9 GDOI Protocol Support for IEC 62351 Security Services 10 draft-weis-gdoi-iec62351-9-10 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 May 1, 2017. 39 Copyright Notice 41 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 60 2. IEC 61850 Protocol Information . . . . . . . . . . . . . . . 4 61 2.1. ID Payload . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . 6 63 2.3. KD Payload . . . . . . . . . . . . . . . . . . . . . . . 10 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 67 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 69 6.2. Informative References . . . . . . . . . . . . . . . . . 16 70 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 . 18 71 Appendix B. Implementation Considerations . . . . . . . . . . . 23 72 B.1. DER Length Fields . . . . . . . . . . . . . . . . . . . . 23 73 B.2. Groups with Multiple Senders . . . . . . . . . . . . . . 23 74 Appendix C. Data Attribute Format . . . . . . . . . . . . . . . 23 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 77 1. Introduction 79 Power substations use Generic Object Oriented Substation Events 80 (GOOSE) protocol [IEC-61850-8-1] to distribute control information to 81 groups of devices using a multicast strategy. Sources within the 82 power substations also distribute IEC 61850-9-2 sampled values data 83 streams [IEC-61850-9-2]. The IEC 62351-9 standard [IEC-62351-9] 84 describes key management methods for the security methods protecting 85 these IEC 61850 messages, including methods of device authentication 86 and authorization, and methods of policy and keying material 87 agreement for IEC 61850 message encryption and data integrity 88 protection. These key management methods include the use of GDOI 89 [RFC6407] to distribute the security policy and session keying 90 material used to protect IEC 61850 messages when the messages are 91 sent to a group of devices. 93 The protection of the messages is defined within IEC 62351-6 94 [IEC-62351-6], IEC 61850-8-1 [IEC-61850-8-1], and IEC 61850-9-2 95 [IEC-61850-9-2]. Protected IEC 61850 messages typically include the 96 output of a Message Authentication Code (MAC) and may also be 97 encrypted using a symmetric cipher such as the Advanced Encryption 98 Standard (AES). 100 Section 5.5.2 of RFC 6407 specifies that the following information 101 needs to be provided in order to fully define a new Security 102 Protocol: 104 o The Protocol-ID for the particular Security Protocol. 106 o The SPI Size 108 o The method of SPI generation 110 o The transforms, attributes, and keys needed by the Security 111 Protocol. 113 This document defines GDOI payloads to distribute policy and keying 114 material to protect IEC 61850 messages, and defines the necessary 115 information to ensure interoperability between IEC 61850 116 implementations. 118 This memo extends RFC 6407 in order to define extensions needed by 119 IEC 62351-9. With the current IANA registry rules setup by RFC 6407, 120 this requires a standards action by the IETF - essentially that means 121 the production of this document. As the relevant IEC specifications 122 are not available to the IETF community, it is not possible for this 123 RFC to fully describe the security considerations applying. 124 Implementers therefore need to depend on the security analysis within 125 the IEC specifications. As two different Standards Development 126 Organizations are involved here, and since group key management is 127 inherently complex, it is possible some security issues have not been 128 identified, so additional analysis of the security of the combined 129 set of specifications may be advisable. 131 1.1. Requirements notation 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in 136 [RFC2119]. 138 1.2. Terminology 140 The following key terms are used throughout this document: 142 Generic Object Oriented Substation Events: Power substation control 143 model defined as per IEC 61850. 145 IEC 61850 message: A message in the IEC 61850 family of protocols 146 carrying control or data between Substation devices. 148 1.3. Acronyms and Abbreviations 150 The following acronyms and abbreviations are used throughout this 151 document 153 AES Advanced Encryption Standard 155 GCKS Group Controller/Key Server 157 GDOI Group Domain of Interpretation 159 GM Group Member 161 GOOSE Generic Object Oriented Substation Events 163 KD Key Download 165 KEK Key Encryption Key 167 MAC Message Authentication Code 169 SA Security Association 171 SPI Security Parameter Index 173 TEK Traffic Encryption Key 175 2. IEC 61850 Protocol Information 177 The following sections describe the GDOI payload extensions that are 178 needed in order to distribute security policy and keying material for 179 the IEC 62351 Security Services. The Identification (ID) Payload is 180 used to describe an IEC 62351 GDOI group. The Security Association 181 (SA) Traffic Encryption Key (TEK) payload is used to describe the 182 policy defined by a Group Controller/Key Server (GCKS) for a 183 particular IEC 62351 traffic selector. No changes are required to 184 the Key Download (KD) Payload, but a mapping of IEC 62351 keys to KD 185 Payload key types is included. 187 All multioctet fields are in network byte order. 189 2.1. ID Payload 191 The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group 192 Member (GM) to declare the group it would like to join. A group is 193 defined by an ID payload as defined in GDOI [RFC6407] and reproduced 194 in Figure 1. 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 199 ! Next Payload ! RESERVED ! Payload Length ! 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 201 ! ID Type ! DOI-Specific ID Data = 0 ! 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 203 ~ Identification Data ~ 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 206 Figure 1: RFC 6407 Identification Payload 208 An ID Type name of ID_OID (value 13) is defined in this memo to 209 specify an Object Identifier (OID) [ITU-T-X.683] encoded using 210 Distinguished Encoding Rules (DER) [ITU-T-X.690]. Associated with 211 the OID may be an OID Specific Payload DER encoded as further 212 defining the group. Several OIDs are specified in [IEC-62351-9] for 213 use with IEC 61850. Each OID represents a GOOSE or Sampled Value 214 protocol, and in some cases IEC 61850 also specifies a particular 215 multicast destination address to be described in the OID Specific 216 Payload field. The format of the ID_OID Identification Data is 217 specified as shown in Figure 2. 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 222 ! OID Length ! OID ~ 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 224 ! OID Specific Payload Length ! OID Specific Payload ~ 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 227 Figure 2: ID_OID Identification Data 229 The ID_OID Identification Data fields are defined as follows: 231 o OID Length (1 octet) -- Length of the OID field. 233 o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER 234 [ITU-T-X.690]. 236 o OID Specific Payload Length (2 octets) -- Length of the OID 237 Specific Payload. Set to zero if the OID does not require an OID 238 Specific Payload. 240 o OID Specific Payload (variable) -- OID specific selector encoded 241 in DER. If OID Specific Payload Length is set to zero this field 242 does not appear in the ID payload. 244 2.2. SA TEK Payload 246 The SA TEK payload contains security attributes for a single set of 247 policy associated with a group TEK. The type of policy to be used 248 with the TEK is described by a Protocol-ID field included in the SA 249 TEK. As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID 250 describes a particular TEK Protocol-Specific Payload definition. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 255 ! Next Payload ! RESERVED ! Payload Length ! 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 257 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 258 +-+-+-+-+-+-+-+-+ ~ 259 ~ ~ 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 262 Figure 3: RFC 6407 SA TEK Payload 264 The Protocol-ID name of GDOI_PROTO_IEC_61850 (value TBD1) is defined 265 in this memo for the purposes of distributing IEC 61850 policy. A 266 GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID 267 Specific Payload that together define the selectors for the network 268 traffic. The selector fields are followed by security policy fields 269 indicating how the specified traffic is to be protected. The 270 GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as 271 shown in Figure 4. 273 0 1 2 3 274 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 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 276 ! OID Length ! OID ~ 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 278 ! OID Specific Payload Length ! OID Specific Payload ~ 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 280 ! SPI ! 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 282 ! Auth Alg ! Enc Alg ! 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 284 ! Remaining Lifetime Value ! 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 286 ! SA Data Attributes ~ 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 289 Figure 4: IEC-61850 SA TEK Payload 291 The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as 292 follows: 294 o OID Length (1 octet) -- Length of the OID field. 296 o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER. 297 OIDs defined in IEC 61850 declare the type of IEC 61850 message to 298 be protected, as defined by [IEC-62351-9]. 300 o OID Specific Payload Length (2 octets) -- Length of the OID 301 Specific Payload. This field is set to zero if the policy does 302 not include an OID Specific Payload. 304 o OID Specific Payload (variable) -- The traffic selector (e.g., 305 multicast address) specific to the OID encoded using DER. Some 306 OID policy settings do not require the use of an OID Specific 307 Payload, in which case this field is not included in the TEK and 308 the OID Specific Payload Length is set to zero. 310 o SPI (4 octets) -- Identifier for the Current Key. This field 311 represents a SPI. 313 o Auth Alg (2 octets) -- Authentication Algorithm ID. Valid values 314 are define in Section 2.2.2. 316 o Enc Alg (2 octets) -- Confidentiality Algorithm ID. Valid values 317 are define in Section 2.2.3. 319 o Remaining Lifetime value (4 octets) -- The number of seconds 320 remaining before this TEK expires. A value of zero (0) shall 321 indicate that the TEK does not have an expire time. 323 o SA Data Attributes (variable length) -- Contains zero or more 324 attributes associated with this SA. Section Section 2.2.4 defines 325 attributes. 327 2.2.1. Selectors 329 The OID and (optionally) an OID Specific Payload that together define 330 the selectors for the network traffic. While they may match the OID 331 and OID Specific Payload that the GM had previously requested in the 332 ID payload, there is no guarantee that this will be the case. 333 Including selectors in the SA TEK is important for at least the 334 following reasons: 336 o The KS policy may direct the KS to return multiple TEKs, each 337 representing different traffic selectors and it is important that 338 every GM receiving the set of TEKs explicitly identify the traffic 339 selectors associated with the TEK. 341 o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, 342 which distributes new or replacement TEKs to group members. Since 343 the GROUPKEY-PUSH message does not contain an ID payload the TEK 344 definition must include the traffic selectors. 346 2.2.2. Authentication Algorithms 348 This memo defines the following Authentication Algorithms for use 349 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5], 350 including requirements on one or more algorithms defined as mandatory 351 to implement. 353 o NONE. Specifies that a Authentication Algorithm is not required, 354 or when the accompanying confidentiality algorithm includes 355 authentication (e.g., AES-GCM-128). See Section 3 for cautionary 356 notes regarding using this value without any confidentiality 357 algorithm. 359 o HMAC-SHA256-128. Specifies the use of SHA-256 [FIPS180-3.2008] 360 combined with HMAC [RFC2104]. The output is truncated to 128 361 bits, as per [RFC2104]. The key size is the size of the hash 362 value produced by SHA-256 (256 bits). 364 o HMAC-SHA256. Specifies the use of SHA-256 [FIPS180-3.2008] 365 combined with HMAC [RFC2104]. The key size is the size of the 366 hash value produced by SHA-256 (256 bits). 368 o AES-GMAC-128. Specifies the use of AES [FIPS197] in the Galois 369 Message Authentication Code (GMAC) mode [SP.800-38D] with a 128 370 bit key size. 372 o AES-GMAC-256. Specifies the use of AES [FIPS197] in the Galois 373 Message Authentication Code (GMAC) mode [SP.800-38D] with a 256 374 bit key size. 376 2.2.3. Confidentiality Algorithms 378 This memo defines the following Confidentiality Algorithms for use 379 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5], 380 including requirements on one or more algorithms defined as mandatory 381 to implement. 383 o NONE. Specifies that Confidentiality is not required. NOTE: See 384 Section 3 for guidance for cautionary notes regarding using this 385 value. 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. 389 This encryption algorithm does not provide authentication and MUST 390 NOT be used with the NONE Authentication Algorithm. 392 o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher 393 Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. 394 This encryption algorithm does not provide authentication and MUST 395 NOT be used with the NONE Authentication Algorithm. 397 o AES-GCM-128. Specifies the use of AES [FIPS197] in the Galois/ 398 Counter Mode (GCM) mode [SP.800-38D] with a 128 bit key size. 399 This encryption algorithm provides authentication and is used with 400 a NONE Authentication Algorithm. 402 o AES-GCM-256. Specifies the use of AES [FIPS197] in the Galois/ 403 Counter Mode (GCM) mode [SP.800-38D] with a 256 bit key size. 404 This encryption algorithm provides authentication and is used with 405 a NONE Authentication Algorithm. 407 2.2.4. SA Attributes 409 The following attributes may be present in an SA TEK. The attributes 410 must follow the format described in Appendix C). 412 2.2.4.1. SA Time Activation Delay (SA_ATD) 414 A GCKS will sometimes distribute an SA TEK in advance of when it is 415 expected to be used. This is communicated to group members using the 416 SA Activation Time Delay (SA_ATD) attribute. When a GM receives an 417 SA_TEK with this attribute, it waits for the number of seconds 418 contained within the attribute before installing it for either 419 transmission or receiving. 421 This Activation Time Delay attribute applies only this SA, and MAY be 422 used in either a GROUPKEY-PULL or GROUPKEY-PUSH exchange. RFC 6407 423 also describe an ACTIVATION_TIME_DELAY attribute for the Group 424 Associated Policy (GAP) payload, which is applied to all Security 425 Associations and restricted to use in a GROUPKEY-PUSH message. If 426 both attributes are included in a GROUPKEY-PUSH payload, the value 427 contained in SA_ATD will be used. 429 2.2.4.2. Key Delivery Assurance (SA_KDA) 431 Group policy can include notifying a multicast source ("Publisher") 432 of an indication of whether multicast receivers ("Subscribers") have 433 previously received the SA TEK. This notification allows a Publisher 434 to set a policy as to whether to activate the new SA TEK or not based 435 on the percentage of Subscribers that are able to receive packets 436 protected by the SA TEK. The attribute value is a number between 0 437 and 100 (inclusive). 439 2.2.5. SPI Discussion 441 As noted in Section 1, RFC 6407 requires that characteristics of a 442 SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is 443 represented as a Key Identifier (KeyID). The SPI size is 4 octets. 444 The SPI is unilaterally chosen by the GCKS using any method chosen by 445 the implementation. However, an implementation needs to take care 446 not to duplicate a SPI value that is currently in use for a 447 particular group. 449 2.3. KD Payload 451 The KD Payload contains group keys for the policy specified in the SA 452 Payload. It is comprised of a set of Key Packets, each of which hold 453 the keying material associated with a SPI (i.e., an IEC 61850 Key 454 Identifier). The RFC 6407 KD payload format is reproduced in 455 Figure 5. 457 0 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 460 ! Next Payload ! RESERVED ! Payload Length ! 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 462 ! Number of Key Packets ! RESERVED2 ! 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 464 ~ Key Packets ~ 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 467 Figure 5: KD Payload 469 Each Key Packet holds the keying material associated with a 470 particular IEC 61850 Key Identifier, although GDOI refers to it as a 471 SPI. The keying material is described in a set of attributes 472 indicating an encryption key, integrity key, etc., in accordance with 473 the security policy of the group as defined by the associated SA 474 Payload. Each Key Packet has the following format, reproduced in 475 Figure 6. 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 480 ! KD Type ! RESERVED ! Key Packet Length ! 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 482 ! SPI Size ! SPI (variable) ~ 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 484 ~ Key Packet Attributes ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 487 Figure 6: Key Packet 489 No changes are needed to GDOI in order to distribute IEC 61850 keying 490 material, but the keys MUST be distributed as defined in Section 5.6 491 of RFC 6407. The KD Type MUST be TEK (1). 493 A key associated with an IEC 61850 Authentication Algorithm 494 (distributed in the Auth Alg field) MUST be distributed as a 495 TEK_INTEGRITY_KEY attribute. The value of the attribute is 496 interpreted according to the type of key distributed in the SA TEK: 498 o HMAC-SHA256-128, HMAC-SHA256. The value is 32 octets. 500 o AES-GMAC-128. The value is 20 octets. The first 16 octets are 501 the 128-bit AES key, and the remaining four octets are used as the 502 salt value in the nonce. 504 o AES-GMAC-256. The value is 36 octets. The first 32 octets are 505 the 256-bit AES key, and the remaining four octets are used as the 506 salt value in the nonce. 508 A key associated with an IEC 61850 Confidentiality Algorithm 509 (distributed in the Enc Alg SA TEK field) MUST be distributed as a 510 TEK_ALGORITHM_KEY attribute. The value of the attribute is 511 interpreted according to the type of key distributed in the SA TEK: 513 o AES-CBC-128. The value is 16 octets. 515 o AES-CBC-256. The value is 32 octets. 517 o AES-GCM-128. The value is 20 octets. The first 16 octets are the 518 128-bit AES key, and the remaining four octets are used as the 519 salt value in the nonce. 521 o AES-GCM-256. The value is 36 octets. The first 32 octets are the 522 256-bit AES key, and the remaining four octets are used as the 523 salt value in the nonce. 525 3. Security Considerations 527 GDOI is a security association (SA) management protocol for groups of 528 senders and receivers. This protocol performs authentication of 529 communicating protocol participants (Group Member, Group Controller/ 530 Key Server). GDOI provides confidentiality of key management 531 messages, and it provides source authentication of those messages. 532 GDOI includes defenses against man-in-middle, connection hijacking, 533 replay, reflection, and denial-of-service (DOS) attacks on unsecured 534 networks. GDOI assumes the network is not secure and may be under 535 the complete control of an attacker. The Security Considerations 536 described in RFC 6407 are relevant to the distribution of GOOSE and 537 sampled values policy as defined in this memo. 539 Message Authentication is an optional property for IEC 62351 Security 540 Services, however when encryption is used authentication MUST also be 541 provided by using an authenticated encryption algorithm such as AES- 542 GCM-128 or by using a specific authentication algorithm such as HMAC- 543 SHA-256. Setting the Authentication Algorithm to NONE, but setting 544 the Confidentiality Algorithm to an algorithm that does not include 545 authentication (i.e., is marked with an N in the "Authenticated 546 Encryption" column of the IEC62351-9 Confidentiality Values IANA 547 Registry) is not safe, and MUST NOT be used. 549 When Message Authentication is used, a common practice is to truncate 550 the output of a MAC and include part of the bits in the integrity 551 protection field of the data security transform. Current guidance in 553 [RFC2104] is to truncate no less than half of the length of the hash 554 output. The authentication algorithm HMAC-SHA256-128 defined in this 555 memo truncates the output to exactly half of the output, which 556 follows this guidance. 558 Confidentiality is an optional security property for IEC 62351 559 Security Services. Confidentiality Algorithm IDs SHOULD be included 560 in the IEC-61850 SA TEK Payload if the IEC 61850 messages are 561 expected to traverse public network links and not protected by 562 another level of encryption (e.g., an encrypted Virtual Private 563 Network). Current cryptographic advice indicates that the use of 564 AES-CBC-128 for confidentiality is sufficient for the foreseeable 565 future [SP.800-131], but some security policies may require the use 566 of AES-CBC-256. 568 IEC 62351 Security Services describes a variety of policy choices for 569 protecting network traffic, including the option of specifying no 570 protection at all. This is enabled with the use of NONE as an 571 Authentication Algorithm and/or Confidentiality Algorithm. The 572 following guidance is given regarding the use of NONE. 574 o Setting both Authentication Algorithm and Confidentiality 575 Algorithm to NONE is possible, but NOT RECOMMENDED. Setting such 576 a policy is sometimes necessary during a migration period, when 577 traffic is being protected incrementally and some traffic has not 578 yet been scheduled for protection. Alternatively, site security 579 policy for some packet flows requires inspection of packet data on 580 the private network followed by network-layer encryption before 581 delivery to a public network. 583 o Setting the Confidentiality Algorithm to NONE, but setting the 584 Authentication Algorithm to a MAC can be an acceptable policy in 585 the following conditions: the disclosed information in the data 586 packets is comprised of raw data values, and the disclosure of the 587 data files is believed to be of no more value to an observer than 588 traffic analysis on the frequency and size of packets protected 589 for confidentiality. Alternatively, site security policy for some 590 packet flows requires inspection of packet data on the private 591 network followed by network-layer encryption before delivery to a 592 public network. 594 o Setting the Authentication Algorithm to NONE, but setting the 595 Confidentiality Algorithm to an algorithm that does not includes 596 authentication is not safe, and MUST NOT be used. 598 4. IANA Considerations 600 The following additions are made to the GDOI payloads registry 601 [GDOI-REG]. 603 A new SA TEK Payload Values - Protocol-ID value is defined. Its type 604 is GDOI_PROTO_IEC_61850, with a value of TBD1. 606 A new registry is added defining Auth Alg values. The Attribute 607 Class is called "IEC62351-9 Authentication Values". The terms 608 Reserved, Expert Review and Private Use are to be applied as defined 609 in [RFC5226]. 611 Name Value 612 ---- ----- 613 Reserved 0 614 NONE 1 615 HMAC-SHA256-128 2 616 HMAC-SHA256 3 617 AES-GMAC-128 4 618 AES-GMAC-256 5 619 Expert Review 6-61439 620 Private Use 61440-65535 622 A new registry is added defining Enc Alg values. The Attribute Class 623 is called "IEC62351-9 Confidentiality Values". The terms Expert 624 Review and Private Use are to be applied as defined in [RFC5226]. 626 Name Value Authenticated Encryption 627 ---- ----- ------------------------ 628 Reserved 0 629 NONE 1 630 AES-CBC-128 2 N 631 AES-CBC-256 3 N 632 AES-GCM-128 4 Y 633 AES-GCM-256 5 Y 634 Expert Review 6-61439 635 Private Use 61440-65535 637 A new registry for SA TEK attributes is defined. The Attribute call 638 is called "GDOI SA TEK Attributes". The terms Expert Review and 639 Expert Review are to be applied as defined in [RFC5226]. In the 640 table, attributes that are defined as TV are marked as Basic (B); 641 attributes that are defined as TLV are marked as Variable (V). 643 Attribute Value Type 644 --------- ----- ---- 645 Reserved 0 646 SA_ATD 1 V 647 SA_KDA 2 B 648 Expert Review 3-28671 649 Private Use 28672-32767 651 A new registry for ID Types is defined for the Identification Payload 652 when the DOI is GDOI. The registry is taken from the ID Types 653 registry for the IPsec DOI, which were previously assumed. Values 654 1-12 are defined identically to the equivalent values in the IPsec 655 DOI. Value 13 is defined in this memo. The terms Expert Review and 656 Private Use are to be applied as defined in [RFC5226]. 658 Name Value 659 ---- ----- 660 Reserved 0 661 ID_IPV4_ADDR 1 662 ID_FQDN 2 663 ID_USER_FQDN 3 664 ID_IPV4_ADDR_SUBNET 4 665 ID_IPV6_ADDR 5 666 ID_IPV6_ADDR_SUBNET 6 667 ID_IPV4_ADDR_RANGE 7 668 ID_IPV6_ADDR_RANGE 8 669 ID_DER_ASN1_DN 9 670 ID_DER_ASN1_GN 10 671 ID_KEY_ID 11 672 ID_LIST 12 673 ID_OID 13 674 Expert Review 14-61439 675 Private Use 61440-65535 677 5. Acknowledgements 679 The authors thanks Sean Turner, Steffen Fries, Yoav Nir, Vincent 680 Roca, Dennis Bourget, and David Boose for their thoughtful reviews, 681 each of which resulted in substantial improvements to the memo. Joe 682 Salowey provided valuable guidance as document shepherd during the 683 publication process. The authors are indebted to Kathleen Moriarty 684 for her agreement to sponsor the publication of the document. 686 6. References 687 6.1. Normative References 689 [IEC-62351-9] 690 International Electrotechnical Commission, "IEC 62351 Part 691 9 - Key Management", IEC 62351-9 , January 2013. 693 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 694 Requirement Levels", BCP 14, RFC 2119, 695 DOI 10.17487/RFC2119, March 1997, 696 . 698 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 699 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 700 DOI 10.17487/RFC5226, May 2008, 701 . 703 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 704 of Interpretation", RFC 6407, DOI 10.17487/RFC6407, 705 October 2011, . 707 6.2. Informative References 709 [FIPS180-3.2008] 710 National Institute of Standards and Technology, "Secure 711 Hash Standard", FIPS PUB 180-3, October 2008, 712 . 715 [FIPS197] "Advanced Encryption Standard (AES)", United States of 716 America, National Institute of Science and 717 Technology, Federal Information Processing Standard (FIPS) 718 197, November 2001. 720 [GDOI-REG] 721 Internet Assigned Numbers Authority, "Group Domain of 722 Interpretation (GDOI) Payload Type Values", IANA Registry, 723 December 2004, . 726 [IEC-61850-8-1] 727 International Electrotechnical Commission, "Specific 728 Communication networks and systems for power utility 729 automation - Part 8-1: Specific communication service 730 mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 731 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. 733 [IEC-61850-9-2] 734 International Electrotechnical Commission, "Communication 735 networks and systems for power utility automation - Part 736 9-2: Specific communication service mapping (SCSM) - 737 Sampled values over ISO/IEC 8802-3", IEC-61850-2 , 738 September 2011. 740 [IEC-62351-6] 741 International Electrotechnical Commission, "Power systems 742 management and associated information exchange - Data and 743 communications security - Part 6: Security for IEC 61850", 744 IEC-62351-6 , June 2007. 746 [IEC-TR-61850-90-5] 747 International Electrotechnical Commission, "Communication 748 networks and systems for power utility automation - Part 749 90-5: Use of IEC 61850 to transmit synchrophasor 750 information according to IEEE C37.118", IEC 62351-9 , May 751 2012. 753 [ITU-T-X.683] 754 "Information technology - Abstract Syntax Notation One 755 (ASN.1): Parameterization of ASN.1 specifications", SERIES 756 X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI 757 networking and system aspects - Abstract Syntax Notation 758 One (ASN.1) , July 2002, . 761 [ITU-T-X.690] 762 "Information technology-ASN.1 encoding rules: 763 Specification of Basic Encoding Rules (BER), Canonical 764 Encoding Rules (CER) and Distinguished Encoding Rules 765 (DER)", SERIES X: DATA NETWORKS, OPEN SYSTEM 766 COMMUNICATIONS AND SECURITY OSI networking and system 767 aspects - Abstract Syntax Notation One (ASN.1) , 2008, 768 . 770 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 771 Hashing for Message Authentication", RFC 2104, 772 DOI 10.17487/RFC2104, February 1997, 773 . 775 [SP.800-131] 776 Barker, E. and A. Roginsky, "Recommendation for the 777 Transitioning of Cryptographic Algorithms and Key 778 Lengths", United States of America, National Institute of 779 Science and Technology DRAFT NIST Special Publication 780 800-131, June 2010. 782 [SP.800-38A] 783 Dworkin, M., "Recommendation for Block Cipher Modes of 784 Operation", United States of America, National Institute 785 of Science and Technology, NIST Special Publication 786 800-38A 2001 Edition, December 2001. 788 [SP.800-38D] 789 Dworkin, M., "Recommendation for Block Cipher Modes of 790 Operation: Galois/Counter Mode (GCM) and GMAC", United 791 States of America, National Institute of Science and 792 Technology, NIST Special Publication 800-38D, November 793 2007. 795 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 797 An IED begins a GROUPKEY-PULL exchange and requests keys and security 798 policy for 61850_UDP_ADDR_GOOSE (OID = 1.2.840.10070.61850.8.1.2 as 799 defined in [IEC-61850-9-2]) and IP multicast address 233.252.0.1 800 encoded as specified in [IEC-61850-9-2]. 802 OID and OID Specific Payload protocol fields are variable length 803 fields. To improve readability, their representations in Figure 7 804 and Figure 8 are "compressed" in the figure, as indicated by a 805 trailing "~" for these fields. Implementations should be aware that 806 because these fields are variably sized, some payload fields may not 807 be conveniently aligned on an even octet. 809 Note 2: The actual DER for the OID Specific Payload field is defined 810 in [IEC-62351-6]. 812 0 1 2 3 813 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 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 815 ! Next Payload ! RESERVED ! Payload Length ! 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 817 ! ID Type=13 ! DOI-Specific ID Data = 0 ! 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 819 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 821 ! OID Specific Payload Len ! OID SP= ~ 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 824 Figure 7: Sample Identification Payload 826 The Key Server responds with the following SA TEK payload including 827 two GDOI_PROTO_IEC_61850 Protocol-Specific TEK payloads in the second 828 GROUPKEY-PULL message. The first one is to be activated immediately, 829 and has a lifetime of 3600 seconds (0x0E10) remaining. The second 830 has a lifetime of 12 hours (0xA8C0) and should be activated in 3300 831 seconds (0x0CE4), which givens a 5 minute (300 seconds) overlap of 832 the two SAs. 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 837 ! Next Payload ! RESERVED ! Payload Length ! 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 839 ! DOI = 2 ! 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 841 ! Situation = 0 ! 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 843 ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 845 ! NP=16 (SA TEK)! RESERVED ! Payload Length ! 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 847 ! Prot-ID=TBD1 ! 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 849 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 851 ! OID Specific Payload Len !OID SP= ~ 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 853 ! SPI=1 ! 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 855 ! AuthAlg=1 (HMAC-SHA256-128) ! EncAlg=2 (AES-CBC-128) ! 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 857 ! Remaining Lifetime=0x0E01 ! 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 859 ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 861 ! NP=0 ! RESERVED ! Payload Length ! 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 863 ! Prot-ID=TBD1 ! 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 865 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 867 ! OID Specific Payload Len !OID SP= ~ 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 869 ! SPI=2 ! 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 871 ! AuthAlg=0 (NONE) ! EncAlg=4 (AES-GCM-128) ! 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 873 ! Remaining Lifetime=0xA8C0 ! 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 875 ! Type=1 (SA_ATD) ! Length=4 ! 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 877 ! Value=0x0CE4 ! 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 880 Figure 8: Sample IEC-61850 SA Payload 882 The IED acknowledges that it is capable and willing to use this 883 policy in the third GROUPKEY-PULL message. In response the KS sends 884 a KD payload to the requesting IED. This concludes the GROUPKEY-PULL 885 exchange. 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 890 ! Next Payload ! RESERVED ! Payload Length ! 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 892 ! Number of Key Packets=2 ! RESERVED2 ! 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 894 ! KD Type=1 ! RESERVED ! Key Packet Length ! 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 896 ! SPI Size=4 ! 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 898 ! SPI=1 ! 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 900 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 902 ! ! 903 ! ! 904 ! ! 905 ! HMAC-SHA256 Key ! 906 ! ! 907 ! ! 908 ! ! 909 ! ! 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 911 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 913 ! ! 914 ! AES-CBC-128 Key ! 915 ! ! 916 ! ! 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 918 ! KD Type=1 ! RESERVED ! Key Packet Length ! 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 920 ! SPI Size=4 ! 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 922 ! SPI=2 ! 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 924 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=20 ! 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 926 ! ! 927 ! AES-GCM-128 Key & Salt ! 928 ! ! 929 ! ! 930 ! ! 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 933 Figure 9: Sample KD Payload 935 Appendix B. Implementation Considerations 937 Several topics have been suggested as useful for implementors. 939 B.1. DER Length Fields 941 The ID and SA TEK payloads defined in this memo include explicit 942 lengths for fields formatted as DER. This includes the OID Length 943 and OID Specific Payload Length fields shown in Figure 2 and 944 Figure 4. Strictly speaking, these lengths are redundant since the 945 length of the DER value is also encoded within the DER fields. It 946 would be possible to determine the lengths of the fields from those 947 encoded values. However, many implementations will find the explicit 948 length fields convenient when constructing and sanity checking the 949 GDOI messages including these payloads. Implementations will thus be 950 spared from manipulating the DER itself when performing activities 951 that do not otherwise require parsing in order to obtain values 952 therein. 954 B.2. Groups with Multiple Senders 956 GCKS policy may specify more than one protected type of IEC 61850 957 message within a GDOI group. This is represented within a GDOI SA 958 Payload by the presence of an SA TEK Payload for each multicast group 959 that is protected as part of group policy. The OID contained in each 960 of the SA TEK Payloads may be identical, but the value of each OID 961 Specific Payload would be unique. Typically, the OID Specific 962 Payload defines a destination address, and typically there is a 963 single sender to that destination address. 965 Appendix C. Data Attribute Format 967 Data attributes attached to an SA TEK following the Data Attribute 968 format described in this section. Data attributes can be in Type/ 969 Value (TV) format (useful when a value is defined to be less than two 970 octets in size) or in Type/Length/Value (TLV) form. 972 1 2 3 973 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 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 !A! Attribute Type ! AF=0 Attribute Length ! 976 !F! ! AF=1 Attribute Value ! 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 . AF=0 Attribute Value . 979 . AF=1 Not Transmitted . 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 Figure 10: Data Attributes 984 The Data Attributes fields are defined as follows: 986 o Attribute Type (2 octets) - Unique identifier for each type of 987 attribute. These attributes are defined as part of the DOI- 988 specific information. The most significant bit, or Attribute 989 Format (AF), indicates whether the data attributes follow the 990 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 991 format. If the AF bit is a zero (0), then the Data Attributes are 992 of the Type/Length/Value (TLV) form. If the AF bit is a one (1), 993 then the Data Attributes are of the Type/Value form. 995 o Attribute Length (2 octets) - Length in octets of the Attribute 996 Value. When the AF bit is a one (1), the Attribute Value is only 997 2 octets and the Attribute Length field is not present. 999 o Attribute Value (variable length) - Value of the attribute 1000 associated with the DOI-specific Attribute Type. If the AF bit is 1001 a zero (0), this field has a variable length defined by the 1002 Attribute Length field. If the AF bit is a one (1), the Attribute 1003 Value has a length of 2 octets. 1005 Authors' Addresses 1007 Brian Weis 1008 Cisco Systems 1009 170 W. Tasman Drive 1010 San Jose, California 95134-1706 1011 USA 1013 Phone: +1 408 526 4796 1014 Email: bew@cisco.com 1016 Maik Seewald 1017 Cisco Systems 1018 Am Soeldnermoos 17 1019 D-85399 Hallbergmoos 1020 Germany 1022 Phone: +49 619 6773 9655 1023 Email: maseewal@cisco.com 1024 Herb Falk 1025 SISCO 1026 6605 19-1/2 Mile Road 1027 Sterling Heights, MI 48314 1028 USA 1030 Phone: +1 586 254 0020 x105 1031 Email: herb@sisconet.com