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