idnits 2.17.1 draft-weis-gdoi-iec62351-9-05.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 26, 2014) is 3441 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: April 29, 2015 H. Falk 6 SISCO 7 October 26, 2014 9 GDOI Protocol Support for IEC 62351 Security Services 10 draft-weis-gdoi-iec62351-9-05 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 April 29, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 58 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . 4 61 2. IEC 61850 Protocol Information . . . . . . . . . . . . . . . . 5 62 2.1. ID Payload . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.2. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . . 6 64 2.3. KD Payload . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 70 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 72 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 6.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 6.2. Informative References . . . . . . . . . . . . . . . . . . 17 76 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 . . 20 78 Appendix B. Implementation Considerations . . . . . . . . . . . . 25 79 B.1. DER Length Fields . . . . . . . . . . . . . . . . . . . . 25 80 B.2. Groups with Multiple Senders . . . . . . . . . . . . . . . 25 82 Appendix C. Data Attribute Format . . . . . . . . . . . . . . . . 26 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 86 1. Introduction 88 Power substations use Generic Object Oriented Substation Events 89 (GOOSE) protocol [IEC-61850-8-1] to distribute control information to 90 groups of devices using a multicast strategy. Sources within the 91 power substations also distribute IEC 61850-9-2 sampled values data 92 streams [IEC-61850-9-2]. The IEC 62351-9 standard [IEC-62351-9] 93 describes key management methods for the security methods protecting 94 these IEC 61850 messages, including methods of device authentication 95 and authorization, and methods of policy and keying material 96 agreement for IEC 61850 message encryption and data integrity 97 protection. These key management methods include the use of GDOI 98 [RFC6407] to distribute the security policy and session keying 99 material used to protect IEC 61850 messages when the messages are 100 sent to a group of devices. 102 The protection of the messages is defined within IEC 62351-6 103 [IEC-62351-6], IEC 61850-8-1 [IEC-61850-8-1], and IEC 61850-9-2 104 [IEC-61850-9-2]. Protected IEC 61850 messages typically include the 105 output of a Message Authentication Code (MAC) and may also be 106 encrypted using a symmetric cipher such as the Advanced Encryption 107 Standard (AES). 109 Section 5.5.2 of RFC 6407 specifies that the following information 110 needs to be provided in order to fully define a new Security 111 Protocol: 113 o The Protocol-ID for the particular Security Protocol. 115 o The SPI Size 117 o The method of SPI generation 119 o The transforms, attributes, and keys needed by the Security 120 Protocol. 122 This document defines GDOI payloads to distribute policy and keying 123 material to protect IEC 61850 messages, and defines the necessary 124 information to ensure interoperability between IEC 61850 125 implementations. 127 1.1. Requirements notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 1.2. Terminology 135 The following key terms are used throughout this document: 137 Generic Object Oriented Substation Events Power substation control 138 model defined as per IEC 61850. 140 IEC 61850 message A message in the IEC 61850 family of protocols 141 carrying control or data between Substation devices. 143 1.3. Acronyms and Abbreviations 145 The following acronyms and abbreviations are used throughout this 146 document 148 AES Advanced Encryption Standard 150 GCKS Group Controller/Key Server 152 GDOI Group Domain of Interpretation 154 GM Group Member 156 GOOSE Generic Object Oriented Substation Events 158 KD Key Download 160 KEK Key Encryption Key 162 MAC Message Authentication Code 164 SA Security Association 166 SPI Security Parameter Index 168 TEK Traffic Encryption Key 170 2. IEC 61850 Protocol Information 172 The following sections describe the GDOI payload extensions that are 173 needed in order to distribute security policy and keying material for 174 the IEC 62351 Security Services. The Identification (ID) Payload is 175 used to describe an IEC 62351 GDOI group. The Security Association 176 (SA) Traffic Encryption Key (TEK) payload is used to describe the 177 policy defined by a Group Controller/Key Server (GCKS) for a 178 particular IEC 62351 traffic selector. No changes are required to 179 the Key Download (KD) Payload, but a mapping of IEC 62351 keys to KD 180 Payload key types is included. 182 2.1. ID Payload 184 The ID payload in a GDOI GROUPKEY-PULL exchange allows the Group 185 Member (GM) to declare the group it would like to join. A group is 186 defined by an ID payload as defined in GDOI [RFC6407] and reproduced 187 in Figure 1. 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 192 ! Next Payload ! RESERVED ! Payload Length ! 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 194 ! ID Type ! DOI-Specific ID Data = 0 ! 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 196 ~ Identification Data ~ 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 199 Figure 1: RFC 6407 Identification Payload 201 An ID Type name of ID_OID (value 13) is defined in this memo to 202 specify an Object Identifier (OID) [ITU-T-X.683] encoded using 203 Distinguished Encoding Rules (DER) [ITU-T-X.690]. Associated with 204 the OID may be an OID Specific Payload DER encoded as further 205 defining the group. Several OIDs are specified in [IEC-62351-9] for 206 use with IEC 61850. Each OID represents a GOOSE or Sampled Value 207 protocol, and in some cases IEC 61850 also specifies a particular 208 multicast destination address to be described in the OID Specific 209 Payload field. The format of the ID_OID Identification Data is 210 specified as shown in Figure 2. 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 215 ! OID Length ! OID ~ 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 217 ! OID Specific Payload Length ! OID Specific Payload ~ 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 220 Figure 2: ID_OID Identification Data 222 The ID_OID Identification Data fields are defined as follows: 224 o OID Length (1 octet) -- Length of the OID field. 226 o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER 227 [ITU-T-X.690]. 229 o OID Specific Payload Length (2 octets) -- Length of the OID 230 Specific Payload. Set to zero if the OID does not require an OID 231 Specific Payload. 233 o OID Specific Payload (variable) -- OID specific selector encoded 234 in DER. If OID Specific Payload Length is set to zero this field 235 does not appear in the ID payload. 237 2.2. SA TEK Payload 239 The SA TEK payload contains security attributes for a single set of 240 policy associated with a group TEK. The type of policy to be used 241 with the TEK is described by a Protocol-ID field included in the SA 242 TEK. As shown in Figure 3 reproduced from RFC 6407, each Protocol-ID 243 describes a particular TEK Protocol-Specific Payload definition. 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 248 ! Next Payload ! RESERVED ! Payload Length ! 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 250 ! Protocol-ID ! TEK Protocol-Specific Payload ~ 251 +-+-+-+-+-+-+-+-+ ~ 252 ~ ~ 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 255 Figure 3: RFC 6407 SA TEK Payload 257 The Protocol-ID name of GDOI_PROTO_IEC_61850 (value TBD1) is defined 258 in this memo for the purposes of distributing IEC 61850 policy. A 259 GDOI_PROTO_IEC_61850 SA TEK includes an OID and (optionally) an OID 260 Specific Payload that together define the selectors for the network 261 traffic. The selector fields are followed by security policy fields 262 indicating how the specified traffic is to be protected. The 263 GDOI_PROTO_IEC_61850 TEK Protocol-Specific Payload is defined as 264 shown in Figure 4. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 269 ! OID Length ! OID ~ 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 271 ! OID Specific Payload Length ! OID Specific Payload ~ 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 273 ! SPI ! 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 275 ! Auth Alg ! Enc Alg ! 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 277 ! Remaining Lifetime Value ! 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 279 ! SA Data Attributes ~ 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 282 Figure 4: IEC-61850 SA TEK Payload 284 The GDOI_PROTO_IEC_61850 SA TEK Payload fields are defined as 285 follows: 287 o OID Length (1 octet) -- Length of the OID field. 289 o OID (variable) -- An ASN.1 ObjectIdentifier encoded using DER. 290 OIDs defined in IEC 61850 declare the type of IEC 61850 message to 291 be protected, as defined by [IEC-62351-9]. 293 o OID Specific Payload Length (2 octets) -- Length of the OID 294 Specific Payload. This field is set to zero if the policy does 295 not include an OID Specific Payload. 297 o OID Specific Payload (variable) -- The traffic selector (e.g., 298 multicast address) specific to the OID encoded using DER. Some 299 OID policy settings do not require the use of an OID Specific 300 Payload, in which case this field is not included in the TEK and 301 the OID Specific Payload Length is set to zero. 303 o SPI (4 octets) -- Identifier for the Current Key. This field 304 represents a SPI. 306 o Auth Alg (2 octets) -- Authentication Algorithm ID. Valid values 307 are define in Section 2.2.2. 309 o Enc Alg (2 octets) -- Confidentiality Algorithm ID. Valid values 310 are define in Section 2.2.3. 312 o Remaining Lifetime value (4 octets) -- The number of seconds 313 remaining before this TEK expires. A value of zero (0) shall 314 indicate that the TEK does not have an expire time. 316 o SA Data Attributes (variable length) -- Contains zero or more 317 attributes associated with this SA. Section Section 2.2.4 defines 318 attributes. 320 2.2.1. Selectors 322 The OID and (optionally) an OID Specific Payload that together define 323 the selectors for the network traffic. While they may match the OID 324 and OID Specific Payload that the GM had previously requested in the 325 ID payload, there is no guarantee that this will be the case. 326 Including selectors in the SA TEK is important for at least the 327 following reasons: 329 o The KS policy may direct the KS to return multiple TEKs, each 330 representing different traffic selectors and it is important that 331 every GM receiving the set of TEKs explicitly identify the traffic 332 selectors associated with the TEK. 334 o The KS policy may include the use of a GDOI GROUPKEY-PUSH message, 335 which distributes new or replacement TEKs to group members. Since 336 the GROUPKEY-PUSH message does not contain an ID payload the TEK 337 definition must include the traffic selectors. 339 2.2.2. Authentication Algorithms 341 This memo defines the following Authentication Algorithms for use 342 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5], 343 including requirements on one or more algorithms defined as mandatory 344 to implement. If NONE is chosen as an Authentication Algorithm, then 345 the Confidentiality Algorithm MUST NOT be NONE. 347 o NONE. Specifies that no Confidentiality Algorithm is to used. 349 o HMAC-SHA256-128. Specifies the use of SHA-256 [FIPS180-3.2008] 350 combined with HMAC [RFC2104]. The output is truncated to 128 351 bits, as per [RFC2104]. The key size is the size of the hash 352 value produced by SHA-256 (256 bits). 354 o HMAC-SHA256. Specifies the use of SHA-256 [FIPS180-3.2008] 355 combined with HMAC [RFC2104]. The key size is the size of the 356 hash value produced by SHA-256 (256 bits). 358 o AES-GMAC-128. Specifies the use of AES [FIPS197] in the Galois 359 Message Authentication Code (GMAC) mode [SP.800-38D] with a 128 360 bit key size. 362 o AES-GMAC-256. Specifies the use of AES [FIPS197] in the Galois 363 Message Authentication Code (GMAC) mode [SP.800-38D] with a 256 364 bit key size. 366 2.2.3. Confidentiality Algorithms 368 This memo defines the following Confidentiality Algorithms for use 369 with this TEK. These algorithms are defined in [IEC-TR-61850-90-5], 370 including requirements on one or more algorithms defined as mandatory 371 to implement. If NONE is chosen as a Confidentiality Algorithm, then 372 the Authentication Algorithm MUST NOT be NONE. 374 o NONE. Specifies that no Confidentiality Algorithm is to used. 376 o AES-CBC-128. Specifies the use of AES [FIPS197] in the Cipher 377 Block Chaining (CBC) mode [SP.800-38A] with a 128 bit key size. 379 o AES-CBC-256. Specifies the use of AES [FIPS197] in the Cipher 380 Block Chaining (CBC) mode [SP.800-38A] with a 256 bit key size. 382 o AES-GCM-128. Specifies the use of AES [FIPS197] in the Galois/ 383 Counter Mode (GCM) mode [SP.800-38D] with a 128 bit key size. 385 o AES-GCM-256. Specifies the use of AES [FIPS197] in the Galois/ 386 Counter Mode (GCM) mode [SP.800-38D] with a 256 bit key size. 388 2.2.4. SA Attributes 390 The following attributes may be present in an SA TEK. The attributes 391 must follow the format described in Appendix C). 393 2.2.4.1. SA Time Activation Delay (SA_ATD) 395 A GCKS will sometimes distribute an SA TEK in advance of when it is 396 expected to be used. This is communicated to group members using the 397 SA Activation Time Delay (SA_ATD) attribute. When a GM receives an 398 SA_TEK with this attribute, it waits for the number of seconds 399 contained within the attribute before installing it for either 400 transmission or receiving. 402 This Activation Time Delay attribute applies only this SA, and MAY be 403 used in either a GROUPKEY-PULL or GROUPKEY-PUSH exchange. RFC 6407 404 also describe an ACTIVATION_TIME_DELAY attribute for the Group 405 Associated Policy (GAP) payload, which is applied to all Security 406 Associations and restricted to use in a GROUPKEY-PUSH message. If 407 both attributes are included in a GROUPKEY-PUSH payload, the value 408 contained in SA_ATD will be used. 410 2.2.4.2. Key Delivery Assurance (SA_KDA) 412 Group policy can include notifying a multicast source ("Publisher") 413 of an indication of whether multicast receivers ("Subscribers") have 414 previously received the SA TEK. This notification allows a Publisher 415 to set a policy as to whether to activate the new SA TEK or not based 416 on the percentage of Subscribers that are able to receive packets 417 protected by the SA TEK. The attribute value is a number between 0 418 and 100 (inclusive). 420 2.2.5. SPI Discussion 422 As noted in Section 1, RFC 6407 requires that characteristics of a 423 SPI must be defined. A SPI in a GDOI_PROTO_IEC_61850 SA TEK is 424 represented as a Key Identifier (KeyID). The SPI size is 4 octets. 425 The SPI is unilaterally chosen by the GCKS using any method chosen by 426 the implementation. However, an implementation needs to take care 427 not to duplicate a SPI value that is currently in use for a 428 particular group. 430 2.3. KD Payload 432 The KD Payload contains group keys for the policy specified in the SA 433 Payload. It is comprised of a set of Key Packets, each of which hold 434 the keying material associated with a SPI (i.e., an IEC 61850 Key 435 Identifier). The RFC 6407 KD payload format is reproduced in 436 Figure 5. 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 441 ! Next Payload ! RESERVED ! Payload Length ! 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 443 ! Number of Key Packets ! RESERVED2 ! 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 445 ~ Key Packets ~ 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 448 Figure 5: KD Payload 450 Each Key Packet holds the keying material associated with a 451 particular IEC 61850 Key Identifier, although GDOI refers to it as a 452 SPI. The keying material is described in a set of attributes 453 indicating an encryption key, integrity key, etc., in accordance with 454 the security policy of the group as defined by the associated SA 455 Payload. Each Key Packet has the following format, reproduced in 456 Figure 6. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 461 ! KD Type ! RESERVED ! Key Packet Length ! 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 463 ! SPI Size ! SPI (variable) ~ 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 465 ~ Key Packet Attributes ~ 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 468 Figure 6: Key Packet 470 No changes are needed to GDOI in order to distribute IEC 61850 keying 471 material, but the keys MUST be distributed as defined in Section 5.6 472 of RFC 6407. The KD Type MUST be TEK (1). 474 A key associated with an IEC 61850 Authentication Algorithm 475 (distributed in the Auth Alg field) MUST be distributed as a 476 TEK_INTEGRITY_KEY attribute. The value of the attribute is 477 interpreted according to the type of key distributed in the SA TEK: 479 o HMAC-SHA256-128, HMAC-SHA256. The value is 32 octets. 481 o AES-GMAC-128. The value is 20 octets. The first 16 octets are 482 the 128-bit AES key, and the remaining four octets are used as the 483 salt value in the nonce. 485 o AES-GMAC-256. The value is 36 octets. The first 32 octets are 486 the 256-bit AES key, and the remaining four octets are used as the 487 salt value in the nonce. 489 A key associated with an IEC 61850 Confidentiality Algorithm 490 (distributed in the Enc Alg SA TEK field) MUST be distributed as a 491 TEK_ALGORITHM_KEY attribute. The value of the attribute is 492 interpreted according to the type of key distributed in the SA TEK: 494 o AES-CBC-128. The value is 16 octets. 496 o AES-CBC-256. The value is 32 octets. 498 o AES-GCM-128. The value is 20 octets. The first 16 octets are the 499 128-bit AES key, and the remaining four octets are used as the 500 salt value in the nonce. 502 o AES-GCM-256. The value is 36 octets. The first 32 octets are the 503 256-bit AES key, and the remaining four octets are used as the 504 salt value in the nonce. 506 3. Security Considerations 508 GDOI is a security association (SA) management protocol for groups of 509 senders and receivers. This protocol performs authentication of 510 communicating protocol participants (Group Member, Group Controller/ 511 Key Server). GDOI provides confidentiality of key management 512 messages, and it provides source authentication of those messages. 513 GDOI includes defenses against man-in-middle, connection hijacking, 514 replay, reflection, and denial-of-service (DOS) attacks on unsecured 515 networks. GDOI assumes the network is not secure and may be under 516 the complete control of an attacker. The Security Considerations 517 described in RFC 6407 are relevant to the distribution of GOOSE and 518 sampled values policy as defined in this memo. 520 Message Authentication is a mandatory property for IEC 62351 Security 521 Services. A common practice is to truncate the output of a MAC and 522 include part of the bits in the integrity protection field of the 523 data security transform. Current guidance in [RFC2104] is to 524 truncate no less than half of the length of the hash output. The 525 authentication algorithm HMAC-SHA256-128 defined in this memo 526 truncates the output to exactly half of the output, which follows 527 this guidance. 529 Confidentiality is an optional security property for IEC 62351 530 Security Services. Confidentiality Algorithm IDs SHOULD be included 531 in the IEC-61850 SA TEK Payload if the IEC 61850 messages are 532 expected to traverse public network links and not protected by 533 another level of encryption (e.g., an encrypted Virtual Private 534 Network). Current cryptographic advice indicates that the use of 535 AES-CBC-128 for confidentiality is sufficient for the foreseeable 536 future [SP.800-131], but some security policies may require the use 537 of AES-CBC-256. 539 4. IANA Considerations 541 The following additions are made to the GDOI payloads registry 542 [GDOI-REG]. 544 A new SA TEK Payload Values - Protocol-ID value is defined. Its type 545 is GDOI_PROTO_IEC_61850, with a value of TBD1. 547 A new registry is added defining Auth Alg values. The Attribute 548 Class is called "IEC62351-9 Authentication Values". The terms Expert 549 Review and Private Use are to be applied as defined in [RFC5226]. 551 Name Value 552 ---- ----- 553 Reserved 0 554 NONE 1 555 HMAC-SHA256-128 2 556 HMAC-SHA256 3 557 AES-GMAC-128 4 558 AES-GMAC-256 5 559 Expert Review 6-61439 560 Private Use 61440-65535 562 A new registry is added defining Enc Alg values. The Attribute Class 563 is called "IEC62351-9 Confidentiality Values". The terms Expert 564 Review and Private Use are to be applied as defined in [RFC5226]. 566 Name Value 567 ---- ----- 568 Reserved 0 569 NONE 1 570 AES-CBC-128 2 571 AES-CBC-256 3 572 AES-GCM-128 4 573 AES-GCM-256 5 574 Expert Review 6-61439 575 Private Use 61440-65535 577 A new registry for SA TEK attributes is defined. The Attribute call 578 is called "GDOI SA TEK Attributes". The terms Expert Review and 579 Expert Review are to be applied as defined in [RFC5226]. In the 580 table, attributes that are defined as TV are marked as Basic (B); 581 attributes that are defined as TLV are marked as Variable (V). 583 Attribute Value Type 584 --------- ----- ---- 585 RESERVED 0 586 SA_ATD 1 V 587 SA_KDA 2 B 588 Expert Review 3-28671 589 Private Use 28672-32767 591 A new registry for ID Types is defined for the Identification Payload 592 when the DOI is GDOI. The registry is taken from the ID Types 593 registry for the IPsec DOI, which were previously assumed. Values 594 1-12 are defined identically to the equivalent values in the IPsec 595 DOI. Value 13 is defined in this memo. The terms Expert Review and 596 Private Use are to be applied as defined in [RFC5226]. 598 Name Value 599 ---- ----- 600 Reserved 0 601 ID_IPV4_ADDR 1 602 ID_FQDN 2 603 ID_USER_FQDN 3 604 ID_IPV4_ADDR_SUBNET 4 605 ID_IPV6_ADDR 5 606 ID_IPV6_ADDR_SUBNET 6 607 ID_IPV4_ADDR_RANGE 7 608 ID_IPV6_ADDR_RANGE 8 609 ID_DER_ASN1_DN 9 610 ID_DER_ASN1_GN 10 611 ID_KEY_ID 11 612 ID_LIST 12 613 ID_OID 13 614 Expert Review 14-61439 615 Private Use 61440-65535 617 5. Acknowledgements 619 The authors thanks Sean Turner, Steffen Fries, Yoav Nir, Vincent 620 Roca, Dennis Bourget, and David Boose for their thoughtful reviews, 621 each of which resulted in substantial improvements to the memo. 623 6. References 625 6.1. Normative References 627 [IEC-62351-9] 628 International Electrotechnical Commission, "IEC 62351 Part 629 9 - Key Management", IEC 62351-9 , January 2013. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, March 1997. 634 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 635 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 636 May 2008. 638 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain 639 of Interpretation", RFC 6407, October 2011. 641 6.2. Informative References 643 [FIPS180-3.2008] 644 National Institute of Standards and Technology, "Secure 645 Hash Standard", FIPS PUB 180-3, October 2008, . 649 [FIPS197] "Advanced Encryption Standard (AES)", United States of 650 America, National Institute of Science and 651 Technology, Federal Information Processing Standard (FIPS) 652 197, November 2001. 654 [GDOI-REG] 655 Internet Assigned Numbers Authority, "Group Domain of 656 Interpretation (GDOI) Payload Type Values", IANA Registry, 657 December 2004, . 660 [IEC-61850-8-1] 661 International Electrotechnical Commission, "Specific 662 Communication networks and systems for power utility 663 automation - Part 8-1: Specific communication service 664 mapping (SCSM) - Mappings to MMS (ISO 9506-1 and ISO 665 9506-2) and to ISO/IEC 8802-3", IEC-61850-8-1 , June 2011. 667 [IEC-61850-9-2] 668 International Electrotechnical Commission, "Communication 669 networks and systems for power utility automation - Part 670 9-2: Specific communication service mapping (SCSM) - 671 Sampled values over ISO/IEC 8802-3", IEC-61850-2 , 672 September 2011. 674 [IEC-62351-6] 675 International Electrotechnical Commission, "Power systems 676 management and associated information exchange - Data and 677 communications security - Part 6: Security for IEC 61850", 678 IEC-62351-6 , June 2007. 680 [IEC-TR-61850-90-5] 681 International Electrotechnical Commission, "Communication 682 networks and systems for power utility automation - Part 683 90-5: Use of IEC 61850 to transmit synchrophasor 684 information according to IEEE C37.118", IEC 62351-9 , 685 May 2012. 687 [ITU-T-X.683] 688 "Information technology - Abstract Syntax Notation One 689 (ASN.1): Parameterization of ASN.1 specifications", SERIES 690 X: DATA NETWORKS AND OPEN SYSTEM COMMUNICATIONS OSI 691 networking and system aspects - Abstract Syntax Notation 692 One (ASN.1) , July 2002, . 695 [ITU-T-X.690] 696 "Information technology-ASN.1 encoding rules: 697 Specification of Basic Encoding Rules (BER), Canonical 698 Encoding Rules (CER) and Distinguished Encoding Rules 699 (DER)", SERIES X: DATA NETWORKS, OPEN SYSTEM 700 COMMUNICATIONS AND SECURITY OSI networking and 701 system aspects - Abstract Syntax Notation One 702 (ASN.1) , 2008, 703 . 705 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 706 Hashing for Message Authentication", RFC 2104, 707 February 1997. 709 [SP.800-131] 710 Barker, E. and A. Roginsky, "Recommendation for the 711 Transitioning of Cryptographic Algorithms and Key 712 Lengths", United States of America, National Institute of 713 Science and Technology DRAFT NIST Special Publication 800- 714 131, June 2010. 716 [SP.800-38A] 717 Dworkin, M., "Recommendation for Block Cipher Modes of 718 Operation", United States of America, National Institute 719 of Science and Technology, NIST Special Publication 800- 720 38A 2001 Edition, December 2001. 722 [SP.800-38D] 723 Dworkin, M., "Recommendation for Block Cipher Modes of 724 Operation: Galois/Counter Mode (GCM) and GMAC", United 725 States of America, National Institute of Science and 726 Technology, NIST Special Publication 800-38D, 727 November 2007. 729 Appendix A. Example ID, SA TEK, and KD payloads for IEC 61850 731 An IED begins a GROUPKEY-PULL exchange and requests keys and security 732 policy for 61850_UDP_ADDR_GOOSE (OID = 1.2.840.10070.61850.8.1.2 as 733 defined in [IEC-61850-9-2]) and IP multicast address 233.252.0.1 734 encoded as specified in [IEC-61850-9-2]. 736 OID and OID Specific Payload protocol fields are variable length 737 fields. To improve readability, their representations in Figure 7 738 and Figure 8 are "compressed" in the figure, as indicated by a 739 trailing "~" for these fields. Implementations should be aware that 740 because these fields are variably sized, some payload fields may not 741 be conveniently aligned on an even octet. 743 Note 2: The actual DER for the OID Specific Payload field is defined 744 in [IEC-62351-6]. 746 0 1 2 3 747 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 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 749 ! Next Payload ! RESERVED ! Payload Length ! 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 751 ! ID Type=13 ! DOI-Specific ID Data = 0 ! 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 753 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 755 ! OID Specific Payload Len ! OID SP= ~ 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 758 Figure 7: Sample Identification Payload 760 The Key Server responds with the following SA TEK payload including 761 two GDOI_PROTO_IEC_61850 Protocol-Specific TEK payloads in the second 762 GROUPKEY-PULL message. The first one is to be activated immediately, 763 and has a lifetime of 3600 seconds (0x0E10) remaining. The second 764 has a lifetime of 12 hours (0xA8C0) and should be activated in 3300 765 seconds (0x0CE4), which givens a 5 minute (300 seconds) overlap of 766 the two SAs. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 771 ! Next Payload ! RESERVED ! Payload Length ! 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 773 ! DOI = 2 ! 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 775 ! Situation = 0 ! 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 777 ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 779 ! NP=16 (SA TEK)! RESERVED ! Payload Length ! 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 781 ! Prot-ID=TBD1 ! 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 783 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 785 ! OID Specific Payload Len !OID SP= ~ 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 787 ! SPI=1 ! 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 789 ! AuthAlg=1 (HMAC-SHA256-128) ! EncAlg=2 (AES-CBC-128) ! 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 791 ! Remaining Lifetime=0x0E01 ! 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 793 ! SA Attr NP=16 (SA TEK) ! RESERVED2 ! 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 795 ! NP=0 ! RESERVED ! Payload Length ! 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 797 ! Prot-ID=TBD1 ! 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 799 ! OID Len=13 ! OID=<06 0B 2A 86 48 CE 56 83 E3 1A 08 01 02> ~ 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 801 ! OID Specific Payload Len !OID SP= ~ 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 803 ! SPI=2 ! 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 805 ! AuthAlg=2 (HMAC-SHA256) ! EncAlg=1 (NONE) ! 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 807 ! Remaining Lifetime=0xA8C0 ! 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 809 ! Type=1 (SA_ATD) ! Length=4 ! 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 811 ! Value=0x0CE4 ! 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 814 Figure 8: Sample IEC-61850 SA Payload 816 The IED acknowledges that it is capable and willing to use this 817 policy in the third GROUPKEY-PULL message. In response the KS sends 818 a KD payload to the requesting IED. This concludes the GROUPKEY-PULL 819 exchange. 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 824 ! Next Payload ! RESERVED ! Payload Length ! 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 826 ! Number of Key Packets=2 ! RESERVED2 ! 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 828 ! KD Type=1 ! RESERVED ! Key Packet Length ! 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 830 ! SPI Size=4 ! 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 832 ! SPI=1 ! 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 834 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 836 ! ! 837 ! ! 838 ! ! 839 ! HMAC-SHA256 Key ! 840 ! ! 841 ! ! 842 ! ! 843 ! ! 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 845 ! TYPE=TEK_ALGORITHM_KEY (1) ! LENGTH=16 ! 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 847 ! ! 848 ! AES-CBC-128 Key ! 849 ! ! 850 ! ! 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 852 ! KD Type=1 ! RESERVED ! Key Packet Length ! 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 854 ! SPI Size=4 ! 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 856 ! SPI=2 ! 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 858 ! TYPE=TEK_INTEGRITY_KEY (2) ! LENGTH=32 (256-bit key) ! 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 860 ! ! 861 ! ! 862 ! ! 863 ! HMAC-SHA256 Key ! 864 ! ! 865 ! ! 866 ! ! 867 ! ! 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-! 869 Figure 9: Sample KD Payload 871 Appendix B. Implementation Considerations 873 Several topics have been suggested as useful for implementors. 875 B.1. DER Length Fields 877 The ID and SA TEK payloads defined in this memo include explicit 878 lengths for fields formatted as DER. This includes the OID Length 879 and OID Specific Payload Length fields shown in Figure 2 and 880 Figure 4. Strictly speaking, these lengths are redundant since the 881 length of the DER value is also encoded within the DER fields. It 882 would be possible to determine the lengths of the fields from those 883 encoded values. However, many implementations will find the explicit 884 length fields convenient when constructing and sanity checking the 885 GDOI messages including these payloads. Implementations will thus be 886 spared from manipulating the DER itself when performing activities 887 that do not otherwise require parsing in order to obtain values 888 therein. 890 B.2. Groups with Multiple Senders 892 GCKS policy may specify more than one protected type of IEC 61850 893 message within a GDOI group. This is represented within a GDOI SA 894 Payload by the presence of an SA TEK Payload for each multicast group 895 that is protected as part of group policy. The OID contained in each 896 of the SA TEK Payloads may be identical, but the value of each OID 897 Specific Payload would be unique. Typically, the OID Specific 898 Payload defines a destination address, and typically there is a 899 single sender to that destination address. XXX what else to say 900 here? 902 Appendix C. Data Attribute Format 904 Data attributes attached to an SA TEK following the Data Attribute 905 format described in this section. Data attributes can be in Type/ 906 Value (TV) format (useful when a value is defined to be less than two 907 octets in size) or in Type/Length/Value (TLV) form. 909 1 2 3 910 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 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 !A! Attribute Type ! AF=0 Attribute Length ! 913 !F! ! AF=1 Attribute Value ! 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 . AF=0 Attribute Value . 916 . AF=1 Not Transmitted . 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 Figure 10: Data Attributes 921 The Data Attributes fields are defined as follows: 923 o Attribute Type (2 octets) - Unique identifier for each type of 924 attribute. These attributes are defined as part of the DOI- 925 specific information. The most significant bit, or Attribute 926 Format (AF), indicates whether the data attributes follow the 927 Type/Length/Value (TLV) format or a shortened Type/Value (TV) 928 format. If the AF bit is a zero (0), then the Data Attributes are 929 of the Type/Length/Value (TLV) form. If the AF bit is a one (1), 930 then the Data Attributes are of the Type/Value form. 932 o Attribute Length (2 octets) - Length in octets of the Attribute 933 Value. When the AF bit is a one (1), the Attribute Value is only 934 2 octets and the Attribute Length field is not present. 936 o Attribute Value (variable length) - Value of the attribute 937 associated with the DOI-specific Attribute Type. If the AF bit is 938 a zero (0), this field has a variable length defined by the 939 Attribute Length field. If the AF bit is a one (1), the Attribute 940 Value has a length of 2 octets. 942 Authors' Addresses 944 Brian Weis 945 Cisco Systems 946 170 W. Tasman Drive 947 San Jose, California 95134-1706 948 USA 950 Phone: +1 408 526 4796 951 Email: bew@cisco.com 953 Maik Seewald 954 Cisco Systems 955 Am Soeldnermoos 17 956 D-85399 Hallbergmoos, 957 Germany 959 Phone: +49 619 6773 9655 960 Email: maseewal@cisco.com 962 Herb Falk 963 SISCO 964 6605 19-1/2 Mile Road 965 Sterling Heights, MI 48314 966 USA 968 Phone: +1 586 254 0020 x105 969 Email: herb@sisconet.com