idnits 2.17.1 draft-weis-gdoi-iec62351-9-01.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 (July 3, 2013) is 3947 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC-62351-9' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEC-TR-61850-90-5' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 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: January 4, 2014 H. Falk 6 SISCO 7 July 3, 2013 9 IEC 62351 Security Protocol support for GDOI 10 draft-weis-gdoi-iec62351-9-01 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 January 4, 2014. 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) [ITU-T-X.683]. Associated 167 with the OID may be an OID Specific Payload further defining the 168 group. Several OIDs are specified in [IEC-62351-9] for use with IEC 169 61850. Each OID represents a GOOSE or Sampled Value protocol, and in 170 some cases IEC 61850 also specifies a particular multicast 171 destination address to be described in the OID Specific Payload 172 field. The format of the ID_OID Identification Data is specified as 173 shown in Figure 2. 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 178 ! OID Length ! OID ~ 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 180 ! OID Specific Payload Length ! OID Specific Payload ~ 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 183 Figure 2: ID_OID Identification Data 185 The ID_OID Identification Data fields are defined as follows: 187 o OID Length (1 octet) -- Length of the OID. 189 o OID (variable) -- An ASN.1 encoded ObjectIdentifier. 191 o OID Specific Payload Length (2 octets) -- Length of the OID 192 Specific Payload. Set to zero if the OID does not require an OID 193 Specific Payload. 195 o OID Specific Payload (variable) -- OID specific selector. If OID 196 Specific Payload Length is set to zero this field does not appear 197 in the ID payload. 199 2.2. SA TEK Payload 201 The SA TEK payload contains security attributes for a single set of 202 policy associated with a group TEK. The type of policy to be used 203 with the TEK is described by a Protocol-ID field included in the SA 204 TEK. As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID 205 describes a particular TEK Protocol-Specific Payload definition. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 210 ! Next Payload ! RESERVED ! Payload Length ! 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 212 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 213 +-+-+-+-+-+-+-+-+ ~ 214 ~ ~ 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 217 Figure 3: RFC 6407 SA TEK Payload 219 The Protocol-ID name of GDOI_PROTO_IEC_61850 (value TBD2) is defined 220 in this memo for the purposes of distributing IEC 61850 policy. An 221 GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID 222 Specific Payload that together define the selectors for the network 223 traffic. The selector fields are followed by security policy fields 224 indicating how the specified traffic is to be protected. The 225 GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as 226 shown in Figure 4. 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 231 ! OID Length ! OID ~ 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 233 ! OID Specific Payload Length ! OID Specific Payload ~ 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 235 ! Current KeyID ! RESERVED ! CK Remaining Lifetime Value ! 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 237 ! CK Auth Alg ! CK Key Alg ! 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 239 ! Next KeyID ! RESERVED ! NK Remaining Lifetime Value ! 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 241 ! NK Auth Alg ! NK Key Alg ! 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 244 Figure 4: IEC-61850 SA TEK Payload 246 The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as 247 follows: 249 o OID Length (1 octet) -- Length of the OID. 251 o OID (variable) -- An ASN.1 encoded ObjectIdentifier defined in IEC 252 61850 that declares the type of traffic to be encrypted. 254 o OID Specific Payload Length (2 octets) -- Length of the OID 255 Specific Payload. This field is set to zero if the policy does 256 not include an OID Specific Payload. 258 o OID Specific Payload (variable) -- The traffic selector (e.g., 259 multicast address) specific to the OID. Some OID policy settings 260 do not require the use of an OID Specific Payload, in which case 261 this field is not included in the TEK and the OID Specific Payload 262 Length is set to zero. 264 o Current KeyID (1 octet) -- Identifier for the Current Key. This 265 field represents a SPI. 267 o RESERVED (1 octet) -- MUST be zero, and MUST be ignored on 268 receipt. 270 o CK Remaining Lifetime value (2 octets) -- The number of minutes 271 prior to the next scheduled Current Key change. A value of zero 272 (0) shall indicate that no key change has been scheduled. 274 o CK Auth Alg (2 octets) -- Current Key Authentication Algorithm ID. 275 Valid values are define in Section 2.2.2. 277 o CK Key Alg (2 octets) -- Current Key Confidentiality Algorithm ID. 278 Valid values are define in Section 2.2.3. 280 o Next KeyID (1 octet) -- Identifier for the Next Key. This field 281 represents a SPI. 283 o RESERVED (1 octet) -- MUST be zero, and MUST be ignored on 284 receipt. 286 o NK Remaining Lifetime value (2 octets) -- The number of minutes 287 prior to the next scheduled Next Key change. A value of zero (0) 288 shall indicate that no key change has been scheduled. 290 o NK Auth Alg (2 octets) -- Next Key Authentication Algorithm ID. 291 Valid values are define in Section 2.2.2. 293 o NK Key Alg (2 octets) -- Next Key Confidentiality Algorithm ID. 294 Valid values are define in Section 2.2.3. 296 2.2.1. Selectors 298 The OID and (optionally) an OID Specific Payload that together define 299 the selectors for the network traffic. While they may match the OID 300 and OID Specific Payload that the GM had previously requested in the 301 ID payload, there is no guarantee that this will be the case. 302 Including selectors in the SA TEK is important for at least the 303 following reasons: 305 o The KS policy may direct the KS to return multiple TEKs, each 306 representing different traffic selectors and it is important that 307 every GM receiving the set of TEKs explicitly identify the traffic 308 selectors associated with the TEK. 310 o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, 311 which distributes new or replacement TEKs to group members. Since 312 the GROUPKEY-PUSH message does not contain an ID payload the TEK 313 definition must include the traffic selectors. 315 2.2.2. Authentication Algorithms 317 This memo defines the following Authentication Algorithms for use 318 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5]. 320 o HMAC-SHA256-80. Specifies the use of SHA-256 [FIPS180-3.2008] 321 combined with HMAC [RFC2104]. The output is truncated to 80 bits. 322 The key size is the size of the hash value produced by SHA-256 323 (256 bits). 325 o HMAC-SHA256-128. Specifies the use of SHA-256 [FIPS180-3.2008] 326 combined with HMAC [RFC2104]. The output is truncated to 128 327 bits. The key size is the size of the hash value produced by SHA- 328 256 (256 bits). 330 o HMAC-SHA256-256. Specifies the use of SHA-256 [FIPS180-3.2008] 331 combined with HMAC [RFC2104]. The key size is the size of the 332 hash value produced by SHA-256 (256 bits). 334 2.2.3. Confidentiality Algorithms 336 This memo defines the following Confidentiality Algorithms for use 337 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5]. 339 o NONE. Specifies that no Confidentiality Algorithm is to used. 341 o AES-CBC-128. Specifies the use of AES [FIPS197] in the Cipher 342 Block Chaining (CBC) mode [SP.800-38A] with a 128 bit key size. 344 o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher 345 Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. 347 2.2.4. SPI Discussion 349 As noted in Section 1, RFC 6407 requires that characteristics of a 350 SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is 351 represented as a Key Identifier (KeyID). It's size is 1 octet. The 352 KeyID is unilaterally chosen by the GCKS using any method chosen by 353 the implementation. However, an implementation needs to take care 354 not to duplicate a KeyID value that is currently in use for a 355 particular group. 357 2.3. Key Download Payload 359 The Key Download Payload contains group keys for the policy specified 360 in the SA Payload. It is comprised of a set of Key Packets, each of 361 which hold the keying material associated with a SPI (i.e., an IEC 362 61850 Key Identifier). The RFC 6407 KD payload format is reproduced 363 in Figure 5. 365 0 1 2 3 366 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 368 ! Next Payload ! RESERVED ! Payload Length ! 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 370 ! Number of Key Packets ! RESERVED2 ! 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 372 ~ Key Packets ~ 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 375 Figure 5: Key Download Payload 377 Each Key Packet holds the keying material associated with a 378 particular IEC 61850 Key Identifier, although GDOI refers to it as a 379 SPI. The keying material is described in a set of attributes 380 indicating an encryption key, integrity key, etc. based upon the 381 security policy of the group as defined by the associated SA Payload. 382 Each Key Packet has the following format, reproduced in Figure 6. 384 0 1 2 3 385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 387 ! KD Type ! RESERVED ! KD Length ! 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 389 ! SPI Size ! SPI (variable) ~ 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 391 ~ Key Packet Attributes ~ 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 394 Figure 6: Key Packet 396 No changes are needed to GDOI in order to distribute IEC 61850 keying 397 material, but the keys MUST be distributed as defined in Section 5.6 398 of RFC 6407. The KD TYPE MUST be TEK (1). A key associated with an 399 IEC 61850 Authentication Algorithm (distributed in the CK Auth Alg 400 and NK Auth Alg SA TEK fields) MUST be distributed as a 401 TEK_INTEGRITY_KEY attribute, and a key associated with an IEC 61850 402 Confidentiality Algorithm (distributed in the CK Key Alg and NK Key 403 Alg SA TEK fields) MUST be distributed as a TEK_ALGORITHM_KEY 404 attribute. 406 3. Security Considerations 408 GDOI is a security association (SA) management protocol for groups of 409 senders and receivers. This protocol performs authentication of 410 communicating protocol participants (Group Member, Group Controller/ 411 Key Server). It provides confidentiality of key management messages, 412 and it provides source authentication of those messages. GDOI 413 includes defenses against man-in-middle, connection hijacking, 414 replay, reflection, and denial-of-service (DOS) attacks on unsecured 415 networks. GDOI assumes the network is not secure and may be under 416 the complete control of an attacker. The Security Considerations 417 described in RFC 6407 are relevant to the distribution of GOOSE and 418 sampled values policy as defined in this memo. 420 4. IANA Considerations 422 A new IPsec Identification Type [ISAKMP-REG] registry value is added. 423 Its type is ID_OID, with a value of TBD1. 425 A new SA TEK Payload Values - Protocol-ID [GDOI-REG] value is 426 defined. Its type is GDOI_PROTO_IEC_61850, with a value of TBD2. 428 A new registry is added to GDOI Payloads [GDOI-REG] defining Auth Alg 429 values. The Attribute Class is called "IEC62351-9 Authentication 430 Values". The terms Specification Required and Private Use are to be 431 applied as defined in [RFC5226]. 433 Name Value 434 ---- ----- 435 Reserved 0 436 HMAC-SHA256-80 1 437 HMAC-SHA256-128 2 438 HMAC-SHA256-256 3 439 Specification Required 4-61439 440 Private Use 61440-65535 442 A new registry is added to GDOI Payloads[GDOI-REG] defining Key Alg 443 values. The Attribute Class is called "IEC62351-9 Confidentiality 444 Values". The terms Specification Required and Private Use are to be 445 applied as defined in [RFC5226]. 447 Name Value 448 ---- ----- 449 Reserved 0 450 NONE 1 451 AES-CBC-128 2 452 AES-CBC-256 3 453 Specification Required 4-61439 454 Private Use 61440-65535 456 5. Acknowledgements 458 TBD 460 6. References 462 6.1. Normative References 464 [IEC-62351-9] 465 International Electrotechnical Commission, "IEC 62351 Part 466 9 - Key Management", IEC 62351-9 , January 2013. 468 [IEC-TR-61850-90-5] 469 International Electrotechnical Commission, "Communication 470 networks and systems for power utility automation - Part 471 90-5: Use of IEC 61850 to transmit synchrophasor 472 information according to IEEE C37.118", IEC 62351-9 , 473 May 2012. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 479 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 480 May 2008. 482 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 483 of Interpretation", RFC 6407, October 2011. 485 6.2. Informative References 487 [FIPS180-3.2008] 488 National Institute of Standards and Technology, "Secure 489 Hash Standard", FIPS PUB 180-3, October 2008, . 493 [FIPS197] "Advanced Encryption Standard (AES)", United States of 494 America, National Institute of Science and 495 Technology, Federal Information Processing Standard (FIPS) 496 197, November 2001. 498 [GDOI-REG] 499 Internet Assigned Numbers Authority, "Group Domain of 500 Interpretation (GDOI) Payload Type Values", IANA Registry, 501 December 2004, . 504 [IEC-61850-8-1] 505 International Electrotechnical Commission, "Specific 506 Communication networks and systems for power utility 507 automation - Part 8-1: Specific communication service 508 mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 509 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. 511 [IEC-61850-9-2] 512 International Electrotechnical Commission, "Communication 513 networks and systems for power utility automation - Part 514 9-2: Specific communication service mapping (SCSM) - 515 Sampled values over ISO/IEC 8802-3", IEC-61850-2 , 516 September 2011. 518 [ISAKMP-REG] 519 Internet Assigned Numbers Authority, ""Magic Numbers" for 520 ISAKMP Protocol", IANA Registry, December 2004, . 524 [ITU-T-X.683] 525 "SERIES X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS 526 OSI networking and system aspects - Abstract Syntax 527 Notation One (ASN.1)", July 2002, . 530 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 531 Hashing for Message Authentication", RFC 2104, 532 February 1997. 534 [SP.800-38A] 535 Dworkin, M., "Recommendation for Block Cipher Modes of 536 Operation", United States of America, National Institute 537 of Science and Technology, NIST Special Publication 800- 538 38A 2001 Edition, December 2001. 540 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 542 An IED requests keys and security policy for 61850_UDP_ADDR_GOOSE (an 543 OID defined in [IEC-61850-9-2]) and IP multicast address 233.252.0.1. 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 548 ! Next Payload ! RESERVED ! Payload Length ! 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 550 ! ID Type=TBD1 ! DOI-Specific ID Data = 0 ! 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 552 ! OID Len ! OID= ~ 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 554 ! OID Specific Payload Len !OID SP= ~ 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 557 Sample Identification Payload 559 The Key Server responds with the following SA TEK payload including a 560 single GDOI_PROTO_IEC_61850 Protocol-Specific TEK payload. 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 565 ! Next Payload ! RESERVED ! Payload Length ! 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 567 ! DOI = 2 ! 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 569 ! Situation = 0 ! 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 571 ! SA Attr NP=16 (SA TEK) | RESERVED2 ! 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 573 ! Protocol-ID=TBD2 ! 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 575 ! OID Len ! OID= ~ 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 577 ! OID Specific Payload Len !OID SP= ~ 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 579 ! Cur KeyID=1 ! RESERVED ! CK Remaining Lifetime=0x3600 ! 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 581 ! CK AuthAlg=1 (HMAC-SHA256-80) ! CK Key Alg=2 (AES-CBC-128) ! 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 583 ! Next KeyID=2 ! RESERVED ! NK Remaining Lifetime=0xffff ! 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 585 ! CK AuthAlg=2 (HMAC-SHA256-128)! CK Key Alg=1 (NONE) ! 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 588 Sample IEC-61850 SA Payload 590 Later, the KS sends a KD payload to the requesting IED. Note that 591 what GDOI calls a "SPI" represents your KeyID. They are exactly the 592 same concept. 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 597 ! Next Payload ! RESERVED ! Payload Length ! 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 599 ! Number of Key Packets=2 ! RESERVED2 ! 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 601 ! KD Type=1 ! RESERVED ! KD Length=30 ! 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 603 ! SPI Size=1 ! SPI=1 ! 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 605 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 607 ! ! 608 ! ! 609 ! ! 610 ! HMAC-SHA256 Key ! 611 ! ! 612 ! ! 613 ! ! 614 ! ! 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 616 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 618 ! ! 619 ! AES-CBC-128 Key ! 620 ! ! 621 ! ! 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 623 ! KD Type=1 ! RESERVED ! KD Length=42 ! 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 625 ! SPI Size=1 ! SPI=2 ! 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 627 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 629 ! ! 630 ! ! 631 ! ! 632 ! HMAC-SHA256 Key ! 633 ! ! 634 ! ! 635 ! ! 636 ! ! 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 639 Sample Key Download Payload 641 Authors' Addresses 643 Brian Weis 644 Cisco Systems 645 170 W. Tasman Drive 646 San Jose, California 95134-1706 647 USA 649 Phone: +1 408 526 4796 650 Email: bew@cisco.com 652 Maik Seewald 653 Cisco Systems 654 Am Soeldnermoos 17 655 D-85399 Hallbergmoos, 656 Germany 658 Phone: +49 619 6773 9655 659 Email: maseewal@cisco.com 661 Herb Falk 662 SISCO 663 6605 19-1/2 Mile Road 664 Sterling Heights, MI 48314 665 USA 667 Phone: +1 586 254 0020 x105 668 Email: herb@sisconet.com