idnits 2.17.1 draft-ohba-6lo-mle-hip-dex-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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2015) is 3112 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154' is mentioned on line 475, but not defined ** Obsolete normative reference: RFC 6253 (Obsoleted by RFC 8002) == Outdated reference: A later version (-05) exists of draft-moskowitz-hip-dex-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Ohba, Ed. 3 Internet-Draft Toshiba 4 Intended status: Experimental October 18, 2015 5 Expires: April 20, 2016 7 An Extension to Mesh Link Establishment (MLE) for Host Identity Protocol 8 Diet Exchange (HIP DEX) 9 draft-ohba-6lo-mle-hip-dex-01 11 Abstract 13 This document defines an extension of MLE (Mesh Link Establishment) 14 protocol to encapsulate HIP DEX key exchange protocol messages. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 20, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 52 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3. Convention . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Key Establishment Phase . . . . . . . . . . . . . . . . . . . 4 56 4. Key Update Phase . . . . . . . . . . . . . . . . . . . . . . 6 57 5. Key Materials . . . . . . . . . . . . . . . . . . . . . . . . 7 58 5.1. Pair-wise Key . . . . . . . . . . . . . . . . . . . . . . 7 59 5.2. Group Keys . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. MLE Security . . . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Certificate Revocation . . . . . . . . . . . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 9.1. MLE TLV Types . . . . . . . . . . . . . . . . . . . . . . 9 65 9.2. HIP Parameter . . . . . . . . . . . . . . . . . . . . . . 9 66 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 69 11.2. External Informative References . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 72 1. Introduction 74 HIP DEX (Host Identity Protocol Diet EXchange) 75 [I-D.moskowitz-hip-dex] is a light-weight key exchange protocol 76 designed for constrained devices. HIP DEX builds on the HIP Base 77 EXchange (HIP BEX) [I-D.ietf-hip-rfc5201-bis] and inherits the 78 transport-agnostic property of HIP BEX. 80 MLE (Mesh Link Establishment) 81 [I-D.kelsey-6lo-mesh-link-establishment] is defined for establishing 82 and configuring secure links in IEEE 802.15.4 mesh networks. MLE 83 assumes that shared keys to secure link-layer frames and MLE messages 84 exchanged between a pair of nodes are pre-configured between the 85 nodes. Therefore, a key exchange protocol is required in order to 86 dynamically configure the required shared keys. While such a key 87 exchange protocol can be run outside MLE, sequentially running a key 88 exchange protocol and MLE as separate protocols requires more message 89 roundtrips. For example, running a HIP DEX 4-way handshake followed 90 by an MLE 3-way handshake requires 3.5 message roundtrips. 92 In this document, an extension to the MLE protocol for encapsulating 93 HIP DEX messages is defined in order to realize optimized key 94 exchange and link establishment for IEEE 802.15.4 mesh networks. 96 1.1. Requirement Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in 101 [RFC2119]. 103 1.2. Acronyms 105 DEX-I1, DEX-R1, DEX-I2, DEX-R2: HIP DEX I1, R1, I2, R2 messages 107 ECDH: Elliptic Curve Diffie-Hellman 109 EI: HIP DEX Key Establishment Initiator 111 ER: HIP DEX Key Establishment Responder 113 LLFC: Link-Layer Frame Counter 115 MIC: MLE Message Integrity Code 117 MLFC: MLE Frame Counter 119 UI: HIP DEX Key Update Initiator 121 UR: HIP DEX Key Update Responder 123 1.3. Convention 125 In the figures of this document, MLE messages marked with '*' are 126 those secured by the MLE protocol. 128 In the key material formats in this document, '|' denotes 129 concatenation operator. 131 2. Overview 133 HIP DEX over MLE consists of two phases, i.e., Key Establishment 134 Phase and Key Update Phase. In Key Establishment Phase, a HIP DEX 135 4-way handshake using I1, R1, I2 and R2 messages is conducted to 136 establish a secure channel between an EI and an ER based on an ECDH 137 shared secret and exchange session key materials over the secure 138 channel. 140 In Key Update Phase, HIP DEX Update messages encrypting session key 141 materials are exchanged between a UI and each UR using an MLE Update 142 Request and Update exchange, followed by a multicast MLE Update 143 message for triggering each UR to simultaneously activate new key 144 materials and reset the associated link-layer frame counters. The UI 145 and UR roles for a pair of nodes may be determined independently of 146 the EI and ER roles that have been taken by the nodes. 148 All MLE messages used for the extension defined in this document 149 SHOULD NOT be protected by link-layer so that a key exchange can be 150 done regardless of the security state of the link-layer. A node that 151 implements this specification MUST allow sending and receiving MLE 152 messages not secured by the link-layer. 154 Secured 802.15.4 MAC frames and MLE messages that use keys 155 established via HIP DEX MUST use a 5-octet Frame Counter so that the 156 Frame Counter does not reach its maximum value throughout the 157 lifetime of a node. An MLE Frame Counter is always carried in the 158 Frame Counter field in the Aux Header of any secured MLE frame. 160 Other than the rules described in this document, the rules defined in 161 [I-D.kelsey-6lo-mesh-link-establishment] are preserved. 163 3. Key Establishment Phase 165 A message exchange diagram for Key Establishment Phase is shown in 166 Figure 1. 168 (EI) (ER) 169 --> Advertisement [HIP{DEX-I1}, Link Quality] 171 <-- Advertisement [HIP{DEX-R1}, Link Quality] 173 --> Link Request [HIP{DEX-I2}, Source Address, Mode, 174 Timeout, Challenge]* 176 <-- Link Accept and Request 177 [HIP{DEX-R2}, LLFC, MLFC, Source Address, Mode, 178 Timeout, Response, Challenge]* 180 --> Link Accept [LLFC, MLFC, Response]* 182 Figure 1: Key Establishment Phase 184 An EI sends an MLE Advertisement message containing a HIP TLV and a 185 Link Quality TLV to an ER. The HIP TLV carries a DEX-I1 packet. How 186 an EI discovers an ER is outside the scope of this document. 188 The ER receives the MLE Advertisement message containing a DEX-I1 189 packet from the EI and sends an MLE Advertisement message containing 190 a HIP TLV and a Link Quality TLV to the EI. The HIP TLV carries a 191 DEX-R1 packet. The DEX-R1 packet MUST contain mandatory R1 192 parameters specified in [I-D.moskowitz-hip-dex]. The DEX-R1 packet 193 MAY contain optional R1 parameters specified in 194 [I-D.moskowitz-hip-dex] and a CERT parameter defined in [RFC6253]. 196 The EI receives the MLE Advertisement message from the ER and sends a 197 secured MLE Link Request message containing HIP, Source Address, 198 Mode, Timeout and Challenge TLVs to the ER. The HIP TLV carries a 199 DEX-I2 packet. The DEX-I2 packet MUST contain mandatory I2 200 parameters specified in [I-D.moskowitz-hip-dex] including an 201 ENCRYPTED_KEY parameter wrapping a session key material of the EI. 202 The DEX-I2 packet MUST also contain an ENCRYPTED parameter wrapping 203 group key materials of the EI. The DEX-I2 packet MAY contain 204 optional I2 parameters specified in [I-D.moskowitz-hip-dex] and a 205 CERT parameter defined in [RFC6253]. The MLE Link Request message is 206 protected by the EI's group MLE key (see section Section 5.2) derived 207 from the EI's group key materials. 209 The ER receives the MLE Link Request message from the EI and extracts 210 the EI's session key material wrapped in the ENCRYPTED_KEY parameter 211 and the EI's group key materials wrapped in the ENCRYPTED parameter. 212 Then the ER sends a secured MLE Link Accept and Request message 213 containing HIP, LLFC, MLFC, Source Address, Mode Timeout, Response 214 and Challenge TLVs to the EI. The HIP TLV carries a DEX-R2 packet. 215 The DEX-R2 packet MUST contain R2 parameters specified in 216 [I-D.moskowitz-hip-dex] including an ENCRYPTED_KEY parameter wrapping 217 a session key material of the ER. The DEX-R2 packet MUST also 218 contain an ENCRYPTED parameter wrapping group key materials of the 219 ER. The DEX-R2 packet MAY contain optional R2 parameters specified 220 in [I-D.moskowitz-hip-dex]. Note that the MIC field of the MLE Link 221 Request message is verified after the ER successfully extracts the 222 EI's group key materials. 224 The EI receives the MLE Link Accept and Request message from the ER 225 and extracts the ER's session key material wrapped in the 226 ENCRYPTED_KEY parameter and the ER's group key materials wrapped in 227 the ENCRYPTED parameter. Then the EI sends a secured MLE Link Accept 228 message containing LLFC TLV, MLFC and Response TLVs to the ER. If a 229 pair-wise key is used by the link-layer, the EI also creates a Pair- 230 wise Key SA with the session key generated by the pair of session key 231 materials of the EI and ER as specified in [I-D.moskowitz-hip-dex]. 232 Note that the MIC field of the MLE Link Accept and Request message is 233 verified after the EI successfully extracts the ER's group key 234 materials. 236 The ER receives the MLE Link Accept message from the EI. If a pair- 237 wise key is used by the link-layer, the EI creates a Pair-wise Key SA 238 with the session key generated by the pair of session key materials 239 of the EI and ER as specified in [I-D.moskowitz-hip-dex]. 241 4. Key Update Phase 243 In Key Update Phase, group key materials are updated. 245 Since the 5-octet Frame Counter space is large enough considering the 246 maximum bandwidth of 250Kbps in 802.15.4 [IEEE802154] to make an 247 assumption that a Frame Counter does not reach its maximum value 248 throughout the lifetime of a node, a mechanism for updating a pair- 249 wise key is not defined in this document. Both link-layer Frame 250 Counters and MLE Frame Counters are not reset in the Key Update 251 Phase. 253 Updating a group key may happen when a node that shares the group key 254 is revoked. A message exchange diagram for group key update is shown 255 in Figure 2. 257 (UI) (UR1)..(URn) 258 // Update 1st peer 259 ----> Update Request [HIP{DEX-UPDATE}, MLFC, Source Address]* 260 <---- Update [HIP{DEX-UPDATE}, MLFC, Source Address]* 261 .. .. 263 // Update n-th peer 264 -----------> Update Request [HIP{DEX-UPDATE}, MLFC, Source Address]* 265 <----------- Update [HIP{DEX-UPDATE}, MLFC, Source Address]* 267 // Key switch notification (multicast) 268 ----> .. --> Update [LLFC, MLFC]* 270 Figure 2: Group Key Update 272 First, a UI performs the following exchange for each UR: 274 o The UI sends an MLE Update Request message containing HIP, MLFC, 275 Source Address and MIC TLVs to a UR. The HIP TLV carries a DEX- 276 UPDATE packet containing SEC, MAC and ENCRYPTED parameters. The 277 ENCRYPTED parameter wraps new group key materials of the UI. 279 o The UR receives the MLE Update Request message from the UI, 280 extracts UI's new group key materials from the ENCRYPTED 281 parameter, activates the UI's new group key materials for incoming 282 frames, and sends an MLE Update message containing HIP, MLFC and 283 Source Address TLVs, where the HIP TLV carries a DEX-UPDATE packet 284 containing ACK and MAC parameters. Note that the MIC field of the 285 MLE Update message is verified after the UR successfully extracts 286 the UI's new group key materials. 288 Once MLE Update Request and Update exchange is completed for all URs, 289 the UI activates the UI's new group key materials for outgoing frames 290 by multicasting an MLE Update message containing LLFC and MLFC TLVs. 291 The MLE Update message is protected by the UI's group MLE key (see 292 section Section 5.2) derived from the UI's new group key materials. 294 When a UR receives the multicast MLE Update message, If the received 295 message is valid, the UR deactivates the UI's old group key materials 296 for incoming frames. 298 A UR that did not receive the multicast MLE Update message may 299 deactivate the UI's old group key materials for incoming frames when 300 it receives a valid MAC frame protected by the link-layer key derived 301 from the UI's new group key materials. 303 5. Key Materials 305 5.1. Pair-wise Key 307 The first 16 octets of the session key corresponding to the HIP DEX 308 Pair-wise SA [I-D.moskowitz-hip-dex] is used as the pairwise link- 309 layer key used for securing unicast link-layer frames with Key 310 Identifier Mode 0x00. 312 An encrypted session key material is contained in an ENCRYPTED_KEY 313 parameter of HIP when the session key is distributed during Key 314 Establishment Phase. 316 5.2. Group Keys 318 Group key materials are created by a node and distributed to peer 319 nodes. 321 The group key materials consist of a 1-octet key identifier (KeyId) 322 and a 16-octet group master key (GroupMasterKey), and encoded as 323 follows: 325 Group Key Materials = KeyId | GroupMasterKey 327 A 16-octet group link-layer key (GroupL2Key), and a 16-octet group 328 MLE key (GroupMLEKey) are derived from GroupMasterKey as follows: 330 GroupL2Key = The first 16-octet of HMAC_SHA256(GroupMasterKey, 331 KeyId). 333 GroupMLEKey = The last 16-octet of HMAC_SHA256(GroupMasterKey, 334 KeyId). 336 A GroupL2Key is used for securing link-layer frames with Key 337 Identifier Mode 0x03 sent by the node that created the group key 338 material. GroupL2Key MUST be used for securing broadcast link-layer 339 frames and MAY also be used for securing unicast link-layer frames. 341 A GroupMLEKey MUST be used for securing MLE messages with Key 342 Identifier Mode 0x03 sent by the node that created the group key 343 material. 345 The group key materials are contained in an GROUP_KEY_MATERIALS 346 parameter of HIP, where the GROUP_KEY_MATERIALS parameter MUST be 347 encrypted in an ENCRYPTED parameter of HIP. 349 6. MLE Security 351 As described in [I-D.kelsey-6lo-mesh-link-establishment], MLE 352 security reuses that of IEEE 802.15.4, i.e., AES-CCM* [IEEE802154]. 353 Since some of the MLE messages (i.e., MLE Link Accept and Request and 354 MLE Accept messages carrying DEX-I2 and DEX-R2 packets, respectively, 355 and unicast MLE Update Request and Update messages carrying a DEX- 356 UPDATE packet) require to be sent unencrypted and only authentication 357 is needed, MIC-64 (Security Level 2) or MIC-128 (Security Level 3) is 358 used to secure MLE messages. MIC-64 is the default security level 359 for securing MLE messages used in this document. GroupMLEKey (see 360 section Section 5.2) with Key Identifier Mode 0x03 and a 5-octet 361 Frame Counter MUST be used for any secured MLE message. 363 7. Certificate Revocation 365 Any MLE message used in this document MAY also contain a CRL 366 (Certificate Revocation List) TLV in which CertificateList defined in 367 [RFC5280] is encoded in the Value field. A node that receives a 368 valid MLE message containing a CRL TLV revokes certificates specified 369 in the TLV and deletes all pair-wise and group keys associated with 370 the revoked certificates. A node MUST reject a CERT parameter for a 371 revoked certificate in Key Establishment Phase. 373 When a CRL TLV is carried in a multicast Update message and forwarded 374 multiple hops, MPL [I-D.ietf-roll-trickle-mcast] MAY be used. In 375 this case, the multicast Update message MUST be secured at the link 376 layer and MUST NOT be secured by MLE as specified in 377 [I-D.kelsey-6lo-mesh-link-establishment]. Detailed MPL parameters 378 for the multicast-based CRL distribution are out of the scope of this 379 document. 381 8. Security Considerations 383 The MLE extension defined in this document uses HIP DEX for key 384 management of computation or memory constrained sensor/actuator 385 devices, and thus it inherits all security considerations made for 386 HIP DEX [I-D.moskowitz-hip-dex]. 388 In order to mitigate security weakness caused by lack of Perfect 389 Forward Secrecy (PFS) in HIP DEX, it is RECOMMENDED to use this MLE 390 extension in conjunction with an additional mechanism to update 391 public/private key pairs and renew HIP DEX SAs using new public/ 392 private key pairs whenever necessary. 394 In both Key Establishment Phase and Key Update Phase, MLE messages 395 are secured using a group key instead of a pairwise key in order to 396 optimize message roundtrips since a group key establishment requires 397 only a half roundtrip. As a result, a Denial of Service (DoS) attack 398 from an insider sharing the group key is possible over MLE TLVs. 400 Due to integration of HIP DEX into MLE, secured MLE messages are 401 authenticated but not encrypted because decryption can be done only 402 after establishing a key. As a result, Source Address, Mode, 403 Timeout, Challenge, Response LLFC and MLFC TLVs are sent in clear, 404 and the cleartext information may be used by attackers for the DoS 405 attack described above. Note that authentication of the MLE message 406 carrying a DEX-I2, DEX-R2 or DEX-UPDATE packet is possible by 407 validating MIC of the MLE message after extracting the authentication 408 key (i.e., GroupMLEKey) from the HIP DEX packet. 410 9. IANA Considerations 412 9.1. MLE TLV Types 414 The following MLE TLV types are to be assigned by IANA based on the 415 policy described in [I-D.kelsey-6lo-mesh-link-establishment]: 417 o HIP-DEX (Value: 9, Length: Variable, Meaning: HIP DEX packet, 418 Reference: this document). 420 o CRL (Value: 10, Length: Variable, Meaning: Certificate Revocation 421 List, Reference: this document). 423 9.2. HIP Parameter 425 The following HIP Parameter is assigned based on the policy described 426 in [I-D.ietf-hip-rfc5201-bis]: 428 o GROUP_KEY_MATERIALS, (Value: 65530, Length: 33, Meaning: Group key 429 materials for MLE and link-layer, Reference: this document). 431 10. Acknowledgments 433 The author would like to acknowledge the helpful comments of Randy 434 Turner, Robert Cragie and Subir Das. 436 11. References 438 11.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 446 Housley, R., and W. Polk, "Internet X.509 Public Key 447 Infrastructure Certificate and Certificate Revocation List 448 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 449 . 451 [RFC6253] Heer, T. and S. Varjonen, "Host Identity Protocol 452 Certificates", RFC 6253, DOI 10.17487/RFC6253, May 2011, 453 . 455 [I-D.moskowitz-hip-dex] 456 Moskowitz, R. and R. Hummen, "HIP Diet EXchange (DEX)", 457 draft-moskowitz-hip-dex-04 (work in progress), July 2015. 459 [I-D.ietf-hip-rfc5201-bis] 460 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 461 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 462 hip-rfc5201-bis-20 (work in progress), October 2014. 464 [I-D.kelsey-6lo-mesh-link-establishment] 465 Kelsey, R., "Mesh Link Establishment", draft-kelsey-6lo- 466 mesh-link-establishment-00 (work in progress), July 2015. 468 [I-D.ietf-roll-trickle-mcast] 469 Hui, J. and R. Kelsey, "Multicast Protocol for Low power 470 and Lossy Networks (MPL)", draft-ietf-roll-trickle- 471 mcast-12 (work in progress), June 2015. 473 11.2. External Informative References 475 [IEEE802154] 476 IEEE standard for Information Technology, "IEEE std. 477 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 478 and Physical Layer (PHY) Specifications for Low-Rate 479 Wireless Personal Area Networks", June 2011. 481 Author's Address 483 Yoshihiro Ohba (editor) 484 Toshiba Electronics Asia 485 20 Pasir Panjang Road, #12-25/28, Mapletree Business City 486 117439 487 Singapore 489 Phone: +65 6278 5252 490 Email: yoshihiro.ohba@toshiba.co.jp