idnits 2.17.1 draft-weis-gdoi-iec62351-9-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6407, but the abstract doesn't seem to directly say this. It does mention RFC6407 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6407, updated by this document, for RFC5378 checks: 2006-06-19) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 11, 2013) is 3971 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 (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Updates: 6407 (once approved) B. Weis 3 Internet-Draft M. Seewald 4 Intended status: Standards Track Cisco Systems 5 Expires: December 13, 2013 H. Falk 6 SISCO 7 June 11, 2013 9 IEC 62351 Security Protocol support for GDOI 10 draft-weis-gdoi-iec62351-9-00 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 assigns 20 updates GDOI to encode the security transforms and keying material 21 for those security protocols. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 13, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 59 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 3 62 2. IEC 61850 Protocol Information . . . . . . . . . . . . . . . . 5 63 2.1. ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 6 65 2.3. Key Download Payload . . . . . . . . . . . . . . . . . . . 9 67 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 75 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 Power substations use Generic Object Oriented Substation Events 84 (GOOSE) protocol [IEC-61850-8-1] to distribute control information to 85 groups of devices using a multicast strategy. Sources within the 86 power substations also distribute IEC 61850-9-2 sampled values data 87 streams [IEC-61850-9-2]. The IEC 62351-9 standard [IEC-62351-9] has 88 specified the use of GDOI [RFC6407] to distribute security policy and 89 session keying material protecting these frames. 91 Section 5.5.2 of RFC 6407 specifies that the following information 92 needs to be provided in order to fully define a new Security 93 Protocol: 95 o The Protocol-ID for the particular Security Protocol. 97 o The SPI Size 99 o The method of SPI generation 101 o The transforms, attributes, and keys needed by the Security 102 Protocol. 104 This memo updates RFC 6407 with policy sufficient for GDOI to 105 distribute policy and keying material for IEC 61850, and defines the 106 necessary information to ensure interoperability between IEC 61850 107 implementations. 109 1.1. Requirements notation 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 1.2. Terminology 117 The following key terms are used throughout this document. 119 Generic Object Oriented Substation Events Power substation control 120 model defined as per IEC 61850. 122 1.3. Acronyms and Abbreviations 124 The following acronyms and abbreviations are used throughout this 125 document 126 GCKS Group Controller/Key Server 128 GDOI Group Domain of Interpretation 130 GM Group Member 132 GOOSE Generic Object Oriented Substation Events 134 KD Key Download Payload 136 KEK Key Encryption Key 138 SA Security Association 140 SPI Security Parameter Index 142 TEK Traffic Encryption Key 144 2. IEC 61850 Protocol Information 146 2.1. ID Payload 148 The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group 149 Member (GM) to declare the group it would like to join. A group is 150 defined by an ID payload as defined in GDOI [RFC6407] and reproduced 151 in Figure 1. 153 0 1 2 3 154 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 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 156 ! Next Payload ! RESERVED ! Payload Length ! 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 158 ! ID Type ! DOI-Specific ID Data = 0 ! 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 160 ~ Identification Data ~ 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 163 Figure 1: RFC 6407 Identification Payload 165 An ID Type name of ID_OID (value TBD1) is defined in this memo to 166 specify an ASN.1 Object Identifier (OID). Associated with the OID 167 may be an OID Specific Payload further defining the group. Several 168 OIDs are specified in [IEC-62351-9] for use with IEC 61850. Each OID 169 represents a GOOSE or Sampled Value protocol, and in some cases IEC 170 61850 also specifies a particular multicast destination address to be 171 described in the OID Specific Payload field. The format of the 172 ID_OID Identification Data is specified as shown in Figure 2. 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 177 ! OID Length ! OID ~ 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 179 ! OID Specific Payload Length ! OID Specific Payload ~ 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 182 Figure 2: ID_OID Identification Data 184 The ID_OID Identification Data fields are defined as follows: 186 o OID Length (1 octet) -- Length of the OID. 188 o OID (variable) -- An ASN.1 encoded ObjectIdentifier. 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 TBD2) 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 ! 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 236 ! CK Remaining Lifetime Value ! 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 238 ! CK Auth Alg ! CK Key Alg ! 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 240 ! Next KeyID ! 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 242 ! NK Remaining Lifetime Value ! 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 244 ! NK Auth Alg ! NK Key Alg ! 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 247 Figure 4: IEC-61850 SA TEK Payload 249 The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as 250 follows: 252 o OID Length (1 octet) -- Length of the OID. 254 o OID (variable) -- An ASN.1 encoded ObjectIdentifier defined in IEC 255 61850 that declares the type of traffic to be encrypted. 257 o OID Specific Payload Length -- Length of the OID Specific Payload. 258 This field is set to zero if the policy does not include an OID 259 Specific Payload. 261 o OID Specific Payload (variable) -- The traffic selector (e.g., 262 multicast address) specific to the OID. Some OID policy settings 263 do not require the use of an OID Specific Payload, in which case 264 this field is not included in the TEK and the OID Specific Payload 265 Length is set to zero. 267 o Current KeyID (1 octet) -- Identifier for the Current Key. This 268 field represents a SPI. 270 o CK Remaining Lifetime value -- The number of seconds prior to the 271 next scheduled Current Key change. A value of zero (0) shall 272 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 NK Remaining Lifetime value -- The number of seconds prior to the 284 next scheduled Next Key change. A value of zero (0) shall 285 indicate that no key change has been scheduled. 287 o NK Auth Alg (2 octets) -- Next Key Authentication Algorithm ID. 288 Valid values are define in Section 2.2.2. 290 o NK Key Alg (2 octets) -- Next Key Confidentiality Algorithm ID. 291 Valid values are define in Section 2.2.3. 293 2.2.1. Selectors 295 The OID and (optionally) an OID Specific Payload that together define 296 the selectors for the network traffic. While they may match the OID 297 and OID Specific Payload that the GM had previously requested in the 298 ID payload, there is no guarantee that this will be the case. 299 Including selectors in the SA TEK is important for at least the 300 following reasons: 302 o The KS policy may direct the KS to return multiple TEKs, each 303 representing different traffic selectors and it is important that 304 every GM receiving the set of TEKs explicitly identify the traffic 305 selectors associated with the TEK. 307 o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, 308 which distributes new or replacement TEKs to group members. Since 309 the GROUPKEY-PUSH message does not contain an ID payload the TEK 310 definition must include the traffic selectors. 312 2.2.2. Authentication Algorithms 314 This memo defines the following Authentication Algorithms for use 315 with this TEK. 317 o HMAC-SHA256. Specifies the use of SHA-256 [FIPS180-3.2008] 318 combined with HMAC [RFC2104]. The output is truncated to 128 319 bits. 321 o AES-GMAC-128. Specifies the use of AES [FIPS197] in the GMAC 322 [SP.800-38D] mode with a 128 bit key size. The output is 128 323 bits. 325 2.2.3. Confidentiality Algorithms 327 This memo defines the following Confidentiality Algorithms for use 328 with this TEK. 330 o AES-CBC-128. Specifies the use of AES [FIPS197] in the Cipher 331 Block Chaining (CBC) mode [SP.800-38A] with a 128 bit key size. 333 o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher 334 Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. 336 2.2.4. SPI Discussion 338 As noted in Section 1, RFC 6407 requires that characteristics of a 339 SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is 340 represented as a Key Identifier (KeyID). It's size is 1 octet. The 341 KeyID is unilaterally chosen by the GCKS using any method chosen by 342 the implementation. However, an implementation needs to take care 343 not to duplicate a KeyID value that is currently in use for a 344 particular group. 346 2.3. Key Download Payload 348 The Key Download Payload contains group keys for the policy specified 349 in the SA Payload. It is comprised of a set of Key Packets, each of 350 which hold the keying material associated with a SPI (i.e., an IEC 351 61850 Key Identifier). The RFC 6407 KD payload format is reproduced 352 in Figure 5. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 357 ! Next Payload ! RESERVED ! Payload Length ! 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 359 ! Number of Key Packets ! RESERVED2 ! 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 361 ~ Key Packets ~ 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 364 Figure 5: Key Download Payload 366 Each Key Packet holds the keying material associated with a 367 particular IEC 61850 Key Identifier, although GDOI refers to it as a 368 SPI. The keying material is described in a set of attributes 369 indicating an encryption key, integrity key, etc. based upon the 370 security policy of the group as defined by the associated SA Payload. 371 Each Key Packet has the following format, reproduced in Figure 6. 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 376 ! KD Type ! RESERVED ! KD Length ! 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 378 ! SPI Size ! SPI (variable) ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 380 ~ Key Packet Attributes ~ 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 383 Figure 6: Key Packet 385 No changes are needed to GDOI in order to distribute IEC 61850 keying 386 material, but the keys MUST be distributed as defined in Section 5.6 387 of RFC 6407. A key associated with an IEC 61850 Authentication 388 Algorithm (distributed in the CK Auth Alg and NK Auth Alg SA TEK 389 fields) MUST be distributed as a TEK_INTEGRITY_KEY attribute, and a 390 key associated with an IEC 61850 Confidentiality Algorithm 391 (distributed in the CK Key Alg and NK Key Alg SA TEK fields) MUST be 392 distributed as a TEK_ALGORITHM_KEY attribute. 394 3. Security Considerations 396 GDOI is a security association (SA) management protocol for groups of 397 senders and receivers. This protocol performs authentication of 398 communicating protocol participants (Group Member, Group Controller/ 399 Key Server). It provides confidentiality of key management messages, 400 and it provides source authentication of those messages. GDOI 401 includes defenses against man-in-middle, connection hijacking, 402 replay, reflection, and denial-of-service (DOS) attacks on unsecured 403 networks. GDOI assumes the network is not secure and may be under 404 the complete control of an attacker. The Security Considerations 405 described in RFC 6407 are relevant to the distribution of GOOSE and 406 sampled values policy as defined in this memo. 408 4. IANA Considerations 410 A new IPsec Identification Type [ISAKMP-REG] registry value is added. 411 Its type is ID_OID, with a value of TBD1. 413 A new SA TEK Payload Values - Protocol-ID [GDOI-REG] value is 414 defined. Its type is GDOI_PROTO_IEC_61850, with a value of TBD2. 416 A new registry is added to GDOI Payloads [GDOI-REG] defining Auth Alg 417 values. The Attribute Class is called "IEC62351-9 Authentication 418 Values". The terms Specification Required and Private Use are to be 419 applied as defined in [RFC5226]. 421 Name Value 422 ---- ----- 423 Reserved 0 424 HMAC-SHA256 1 425 AES-CMAC-128 2 426 Specification Required 4-61439 427 Private Use 61440-65535 429 A new registry is added to GDOI Payloads[GDOI-REG] defining Key Alg 430 values. The Attribute Class is called "IEC62351-9 Confidentiality 431 Values". The terms Specification Required and Private Use are to be 432 applied as defined in [RFC5226]. 434 Name Value 435 ---- ----- 436 Reserved 0 437 AES-CBC-128 1 438 AES-CBC-256 2 439 Specification Required 4-61439 440 Private Use 61440-65535 442 5. Acknowledgements 444 TBD 446 6. References 448 6.1. Normative References 450 [IEC-62351-9] 451 International Electrotechnical Commission, "IEC 62351 Part 452 9 - Key Management", IEC 62351-9 , January 2013. 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, March 1997. 457 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 458 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 459 May 2008. 461 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 462 of Interpretation", RFC 6407, October 2011. 464 6.2. Informative References 466 [FIPS180-3.2008] 467 National Institute of Standards and Technology, "Secure 468 Hash Standard", FIPS PUB 180-3, October 2008, . 472 [FIPS197] "Advanced Encryption Standard (AES)", United States of 473 America, National Institute of Science and 474 Technology, Federal Information Processing Standard (FIPS) 475 197, November 2001. 477 [GDOI-REG] 478 Internet Assigned Numbers Authority, "Group Domain of 479 Interpretation (GDOI) Payload Type Values", IANA Registry, 480 December 2004, . 483 [IEC-61850-8-1] 484 International Electrotechnical Commission, "Specific 485 Communication networks and systems for power utility 486 automation - Part 8-1: Specific communication service 487 mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 488 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. 490 [IEC-61850-9-2] 491 International Electrotechnical Commission, "Communication 492 networks and systems for power utility automation - Part 493 9-2: Specific communication service mapping (SCSM) - 494 Sampled values over ISO/IEC 8802-3", IEC-61850-2 , 495 September 2011. 497 [ISAKMP-REG] 498 Internet Assigned Numbers Authority, ""Magic Numbers" for 499 ISAKMP Protocol", IANA Registry, December 2004, . 503 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 504 Hashing for Message Authentication", RFC 2104, 505 February 1997. 507 [SP.800-38A] 508 Dworkin, M., "Recommendation for Block Cipher Modes of 509 Operation", United States of America, National Institute 510 of Science and Technology, NIST Special Publication 800- 511 38A 2001 Edition, December 2001. 513 [SP.800-38D] 514 Dworkin, M., "Recommendation for Block Cipher Modes of 515 Operation", United States of America, National Institute 516 of Science and Technology, NIST Special Publication 800- 517 38D 2007 Edition, November 2007. 519 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 521 An IED requests keys and security policy for 61850_UDP_ADDR_GOOSE (an 522 OID defined in [IEC-61850-9-2]) and IP multicast address 233.252.0.1. 524 0 1 2 3 525 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 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 527 ! Next Payload ! RESERVED ! Payload Length ! 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 529 ! ID Type=TBD1 ! DOI-Specific ID Data = 0 ! 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 531 ! OID Len ! OID= ~ 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 533 ! OID Specific Payload Len !OID SP= ~ 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 536 Sample Identification Payload 538 The Key Server responds with the following SA TEK payload including a 539 single GDOI_PROTO_IEC_61850 Protocol-Specific TEK payload. 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 544 ! Next Payload ! RESERVED ! Payload Length ! 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 546 ! DOI = 2 ! 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 548 ! Situation = 0 ! 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 550 ! SA Attr NP=16 (SA TEK) | RESERVED2 ! 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 552 ! Protocol-ID=TBD2 ! 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 554 ! OID Len ! OID= ~ 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 556 ! OID Specific Payload Len !OID SP= ~ 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 558 ! Cur KeyID=1 ! 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 560 ! CK Remaining Lifetime Value=0x3600 ! 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 562 ! CK AuthAlg=1 ! CK Key Alg=1 ! 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 564 ! Next KeyID=2 ! 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 566 ! NK Remaining Lifetime Value=0xffff ! 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 568 ! CK AuthAlg=2 ! CK Key Alg=1 ! 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 571 Sample IEC-61850 SA Payload 573 Later, the KS sends a KD payload to the requesting IED. Note that 574 what GDOI calls a "SPI" represents your KeyID. They are exactly the 575 same concept. 577 0 1 2 3 578 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 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 580 ! Next Payload ! RESERVED ! Payload Length ! 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 582 ! Number of Key Packets=2 ! RESERVED2 ! 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 584 ! KD Type=1 ! RESERVED ! KD Length=30 ! 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 586 ! SPI Size=1 ! SPI=1 ! 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 588 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=20 ! 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 590 ! ! 591 ! ! 592 ! HMAC-SHA256 Key ! 593 ! ! 594 ! ! 595 ! ! 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 597 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 599 ! ! 600 ! AES-CBC-128 Key ! 601 ! ! 602 ! ! 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 604 ! KD Type=1 ! RESERVED ! KD Length=42 ! 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 606 ! SPI Size=1 ! SPI=2 ! 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 608 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 ! 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 610 ! ! 611 ! AES-GMAC-128 Key ! 612 ! ! 613 ! ! 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 615 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 617 ! ! 618 ! AES-CBC-128 Key ! 619 ! ! 620 ! ! 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 623 Sample Key Download Payload 625 Authors' Addresses 627 Brian Weis 628 Cisco Systems 629 170 W. Tasman Drive 630 San Jose, California 95134-1706 631 USA 633 Phone: +1-408-526-4796 634 Email: bew@cisco.com 636 Maik Seewald 637 Cisco Systems 638 Am Soeldnermoos 17 639 D-85399 Hallbergmoos, 640 Germany 642 Phone: +49 619 6773 9655 643 Email: maseewal@cisco.com 645 Herb Falk 646 SISCO 648 Phone: 649 Email: herb@sisconet.com