idnits 2.17.1 draft-ietf-hip-dex-20.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 (May 21, 2020) is 1436 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Experimental RFC: RFC 6261 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP WG R. Moskowitz, Ed. 3 Internet-Draft HTT Consulting 4 Intended status: Standards Track R. Hummen 5 Expires: November 22, 2020 Hirschmann Automation and Control 6 M. Komu 7 Ericsson 8 May 21, 2020 10 HIP Diet EXchange (DEX) 11 draft-ietf-hip-dex-20 13 Abstract 15 This document specifies the Host Identity Protocol Diet EXchange (HIP 16 DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The 17 HIP DEX protocol design aims at reducing the overhead of the employed 18 cryptographic primitives by omitting public-key signatures and hash 19 functions. 21 The HIP DEX protocol is primarily designed for computation or memory- 22 constrained sensor/actuator devices. Like HIPv2, it is expected to 23 be used together with a suitable security protocol such as the 24 Encapsulated Security Payload (ESP) for the protection of upper layer 25 protocol data. Unlike HIPv2, HIP DEX does not support Forward 26 Secrecy (FS), and MUST only be used on devices where FS is 27 prohibitively expensive. In addition, HIP DEX can also be used as a 28 keying mechanism for security primitives at the MAC layer, e.g., for 29 IEEE 802.15.4 networks. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 22, 2020. 48 Copyright Notice 50 Copyright (c) 2020 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. The HIP Diet EXchange (DEX) . . . . . . . . . . . . . . . 5 67 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 68 1.3. Memo Structure . . . . . . . . . . . . . . . . . . . . . 7 69 2. Terms, Notation and Definitions . . . . . . . . . . . . . . . 7 70 2.1. Requirements Terminology . . . . . . . . . . . . . . . . 7 71 2.2. Notation . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Host Identity (HI) and its Structure . . . . . . . . . . . . 9 74 3.1. Host Identity Tag (HIT) . . . . . . . . . . . . . . . . . 10 75 3.2. Generating a HIT from an HI . . . . . . . . . . . . . . . 11 76 3.2.1. Why Introduce FOLD . . . . . . . . . . . . . . . . . 11 77 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 78 4.1. Creating a HIP Association . . . . . . . . . . . . . . . 12 79 4.1.1. HIP Puzzle Mechanism . . . . . . . . . . . . . . . . 14 80 4.1.2. HIP State Machine . . . . . . . . . . . . . . . . . . 15 81 4.1.3. HIP DEX Security Associations . . . . . . . . . . . . 19 82 4.1.4. User Data Considerations . . . . . . . . . . . . . . 20 83 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 20 84 5.1. Payload Format . . . . . . . . . . . . . . . . . . . . . 20 85 5.2. HIP Parameters . . . . . . . . . . . . . . . . . . . . . 20 86 5.2.1. DH_GROUP_LIST . . . . . . . . . . . . . . . . . . . . 21 87 5.2.2. HIP_CIPHER . . . . . . . . . . . . . . . . . . . . . 21 88 5.2.3. HOST_ID . . . . . . . . . . . . . . . . . . . . . . . 22 89 5.2.4. HIT_SUITE_LIST . . . . . . . . . . . . . . . . . . . 23 90 5.2.5. ENCRYPTED_KEY . . . . . . . . . . . . . . . . . . . . 23 91 5.2.6. I_NONCE . . . . . . . . . . . . . . . . . . . . . . . 24 92 5.3. HIP Packets . . . . . . . . . . . . . . . . . . . . . . . 24 93 5.3.1. I1 - the HIP Initiator Packet . . . . . . . . . . . . 25 94 5.3.2. R1 - the HIP Responder Packet . . . . . . . . . . . . 26 95 5.3.3. I2 - the Second HIP Initiator Packet . . . . . . . . 28 96 5.3.4. R2 - the Second HIP Responder Packet . . . . . . . . 29 97 5.4. ICMP Messages . . . . . . . . . . . . . . . . . . . . . . 30 98 6. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 30 99 6.1. Solving the Puzzle . . . . . . . . . . . . . . . . . . . 31 100 6.2. HIP_MAC Calculation and Verification . . . . . . . . . . 31 101 6.2.1. CMAC Calculation . . . . . . . . . . . . . . . . . . 31 102 6.3. HIP DEX KEYMAT Generation . . . . . . . . . . . . . . . . 32 103 6.4. Initiation of a HIP Diet EXchange . . . . . . . . . . . . 35 104 6.5. Processing Incoming I1 Packets . . . . . . . . . . . . . 35 105 6.6. Processing Incoming R1 Packets . . . . . . . . . . . . . 36 106 6.7. Processing Incoming I2 Packets . . . . . . . . . . . . . 39 107 6.8. Processing Incoming R2 Packets . . . . . . . . . . . . . 42 108 6.9. Processing Incoming NOTIFY Packets . . . . . . . . . . . 43 109 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets . . . . . 44 110 6.11. Handling State Loss . . . . . . . . . . . . . . . . . . . 44 111 7. HIP Policies . . . . . . . . . . . . . . . . . . . . . . . . 44 112 7.1. HIT/HI ACL . . . . . . . . . . . . . . . . . . . . . . . 45 113 8. Interoperability between HIP DEX and HIPv2 . . . . . . . . . 45 114 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 115 9.1. Need to Validate Public Keys . . . . . . . . . . . . . . 47 116 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 117 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 118 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49 119 12.1. Changes in draft-ietf-hip-dex-20 . . . . . . . . . . . . 49 120 12.2. Changes in draft-ietf-hip-dex-19 . . . . . . . . . . . . 49 121 12.3. Changes in draft-ietf-hip-dex-18 . . . . . . . . . . . . 50 122 12.4. Changes in draft-ietf-hip-dex-17 . . . . . . . . . . . . 50 123 12.5. Changes in draft-ietf-hip-dex-16 . . . . . . . . . . . . 50 124 12.6. Changes in draft-ietf-hip-dex-15 . . . . . . . . . . . . 50 125 12.7. Changes in draft-ietf-hip-dex-14 . . . . . . . . . . . . 50 126 12.8. Changes in draft-ietf-hip-dex-12 and 13 . . . . . . . . 50 127 12.9. Changes in draft-ietf-hip-dex-11 and 12 . . . . . . . . 50 128 12.10. Changes in draft-ietf-hip-dex-11 . . . . . . . . . . . . 51 129 12.11. Changes in draft-ietf-hip-dex-10 . . . . . . . . . . . . 51 130 12.12. Changes in draft-ietf-hip-dex-09 . . . . . . . . . . . . 51 131 12.13. Changes in draft-ietf-hip-dex-05 . . . . . . . . . . . . 51 132 12.14. Changes in draft-ietf-hip-dex-04 . . . . . . . . . . . . 51 133 12.15. Changes in draft-ietf-hip-dex-03 . . . . . . . . . . . . 51 134 12.16. Changes in draft-ietf-hip-dex-02 . . . . . . . . . . . . 52 135 12.17. Changes in draft-ietf-hip-dex-01 . . . . . . . . . . . . 52 136 12.18. Changes in draft-ietf-hip-dex-00 . . . . . . . . . . . . 52 137 12.19. Changes in draft-moskowitz-hip-rg-dex-06 . . . . . . . . 52 138 12.20. Changes in draft-moskowitz-hip-dex-00 . . . . . . . . . 52 139 12.21. Changes in draft-moskowitz-hip-dex-01 . . . . . . . . . 52 140 12.22. Changes in draft-moskowitz-hip-dex-02 . . . . . . . . . 53 141 12.23. Changes in draft-moskowitz-hip-dex-03 . . . . . . . . . 53 142 12.24. Changes in draft-moskowitz-hip-dex-04 . . . . . . . . . 53 143 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 144 13.1. Normative References . . . . . . . . . . . . . . . . . . 54 145 13.2. Informative References . . . . . . . . . . . . . . . . . 55 146 Appendix A. Password-based two-factor authentication during the 147 HIP DEX handshake . . . . . . . . . . . . . . . . . 57 148 Appendix B. IESG Considerations . . . . . . . . . . . . . . . . 57 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 151 1. Introduction 153 This document specifies the Host Identity Protocol Diet EXchange (HIP 154 DEX). HIP DEX is derived from the Base EXchange (BEX) of the Host 155 Identity Protocol Version 2 (HIPv2) [RFC7401]. HIP DEX preserves the 156 protocol semantics as well as the general packet structure of HIPv2. 157 Hence, it is recommended that [RFC7401] is well-understood before 158 reading this document. 160 The main differences between HIP BEX and HIP DEX are: 162 1. HIP DEX uses a different set of cryptographic primitives compared 163 to HIP BEX with the goal to reduce the protocol overhead: 165 * Peer authentication and key agreement in HIP DEX are based on 166 static Elliptic Curve Diffie-Hellman (ECDH) key pairs. This 167 replaces the use of public-key signatures and ephemeral 168 Diffie-Hellman key pairs in HIPv2. 170 * HIP DEX uses AES-CTR for symmetric-key encryption of HIP 171 payloads and AES-CMAC as its MACing function. In contrast, 172 HIPv2 currently supports AES-CBC for encryption and HMAC-SHA- 173 1, HMAC-SHA-256, or HMAC-SHA-384 for MACing. 175 * HIP DEX defines a simple fold function to efficiently generate 176 HITs, whereas the HIT generation of HIPv2 is based on SHA-1, 177 SHA-256, or SHA-384. 179 2. HIP DEX forfeits the HIPv2 Forward Secrecy property due to the 180 removal of the ephemeral Diffie-Hellman key agreement. As this 181 weakens the security properties of HIP DEX, it MUST be used only 182 with constrained devices where this is prohibitively expensive as 183 further explained in Section 1.2. 185 3. HIP DEX forfeits the use of digital signatures with the removal 186 of a hash function. Peer authentication with HIP DEX, therefore, 187 is based on the use of the ECDH derived key in the HIP_MAC 188 parameter. 190 4. With HIP DEX, the ECDH derived key is only used to protect HIP 191 packets. Separate session key(s) are used to protect the 192 transmission of upper layer protocol data. These session key(s) 193 are established via a new secret exchange during the handshake. 195 5. HIP DEX introduces a new, optional retransmission strategy that 196 is specifically designed to handle potentially extensive 197 processing times of the employed cryptographic operations on 198 computationally constrained devices. 200 By eliminating the need for public-key signatures and the ephemeral 201 DH key agreement, HIP DEX reduces the computational, energy, 202 transmission, and memory requirements for public-key cryptography 203 (see [LN08]) in the HIPv2 protocol design. This makes HIP DEX 204 especially suitable for constrained devices as defined in [RFC7228]. 206 This document focuses on the protocol specifications related to 207 differences between HIP BEX and HIP DEX. Where differences are not 208 called out explicitly, the protocol specification of HIP DEX is the 209 same as defined in [RFC7401]. 211 1.1. The HIP Diet EXchange (DEX) 213 The HIP Diet EXchange is a two-party cryptographic protocol used to 214 establish a secure communication context between hosts. The first 215 party is called the Initiator and the second party the Responder. 216 The four-packet exchange helps to make HIP DEX Denial of Service 217 (DoS) resilient. The Initiator and the Responder exchange their 218 static Elliptic Curve Diffie-Hellman (ECDH) keys in the R1 and I2 219 handshake packet. The parties then authenticate each other in the I2 220 and R2 handshake packets based on the ECDH-derived keying material. 221 The Initiator and the Responder additionally transmit keying material 222 for the session key in these last two handshake packets (I2 and R2). 223 This is to prevent overuse of the static ECDH-derived keying 224 material. Moreover, the Responder starts a puzzle exchange in the R1 225 packet and the Initiator completes this exchange in the I2 packet 226 before the Responder performs computationally expensive operations or 227 stores any state from the exchange. Given this handshake structure, 228 HIP DEX operationally is very similar to HIP BEX. Moreover, the 229 employed model is also fairly equivalent to 802.11-2007 230 [IEEE.802-11.2007] Master Key and Pair-wise Transient Key, but 231 handled in a single exchange. 233 HIP DEX does not have the option to encrypt the Host Identity of the 234 Initiator in the I2 packet. The Responder's Host Identity also is 235 not protected. Thus, contrary to HIPv2, HIP DEX does not provide for 236 end-point anonymity and any signaling (i.e., HOST_ID parameter 237 contained with an ENCRYPTED parameter) that indicates such anonymity 238 should be ignored. 240 As in [RFC7401], data packets start to flow after the R2 packet. The 241 I2 and R2 packets may carry a data payload in the future. The 242 details of this may be defined later. 244 An existing HIP association can be updated with the update mechanism 245 defined in [RFC7401]. Likewise, the association can be torn down 246 with the defined closing mechanism for HIPv2 if it is no longer 247 needed. Standard HIPv2 uses a HIP_SIGNATURE to authenticate the 248 association close operation, but since DEX does not provide for 249 signatures, the usual per-message MAC suffices. 251 Finally, HIP DEX is designed as an end-to-end authentication and key 252 establishment protocol. As such, it can be used in combination with 253 Encapsulated Security Payload (ESP) [RFC7402] as well as with other 254 end-to-end security protocols. In addition, HIP DEX can also be used 255 as a keying mechanism for security primitives at the MAC layer, e.g., 256 for IEEE 802.15.4 networks [IEEE.802-15-4.2011]. It is worth 257 mentioning that the HIP DEX base protocol does not cover all the 258 fine-grained policy control found in Internet Key Exchange Version 2 259 (IKEv2) [RFC7296] that allows IKEv2 to support complex gateway 260 policies. Thus, HIP DEX is not a replacement for IKEv2. 262 1.2. Applicability 264 HIP DEX achieves its lightweight nature in large part due to the 265 intentional removal of Forward Secrecy (FS) from the key exchange. 266 Current mechanisms to achieve FS use an authenticated ephemeral 267 Diffie-Hellman exchange (e.g., SIGMA or PAKE). HIP DEX targets usage 268 on devices where even the most lightweight ECDH exchange is 269 prohibitively expensive for recurring (ephemeral) use. For example, 270 experience with the 8-bit 8051-based ZWAVE ZW0500 microprocessor has 271 shown that EC25519 keypair generation exceeds 10 seconds and consumes 272 significant energy (i.e., battery resources). Even the ECDH 273 multiplication for the HIP DEX static-static key exchange takes 8-9 274 seconds, again with measurable energy consumption. The ECDH 275 multiplication resource consumption via a static EC25519 keypair is 276 tolerable as a one-time event during provisioning, but would render 277 the protocol unsuitable for use on these devices if it was required 278 to be a recurring part of the protocol. Further, for devices 279 constrained in this manner, a FS-enabled protocol's cost will likely 280 provide little gain. Since the resulting "FS" key, likely produced 281 during device deployment, would typically end up being used for the 282 remainder of the device's lifetime. 284 With such a usage pattern, the inherent benefit of ephemeral keys is 285 not realized. The security properties of such usage are very similar 286 to those of using a statically provisioned symmetric pre-shared key, 287 in that there remains a single PSK in static storage that is 288 susceptible to exfiltration/compromise, and compromise of that key in 289 effect compromises the entire protocol for that node. HIP DEX 290 achieves marginally better security properties by computing the 291 effective long-term PSK from a DH exchange, so that the provisioning 292 service is not required to be part of the risk surface due to also 293 possessing the PSK. 295 If the device is not able to generate the ECDH keypair, the 296 provisioning service can generate and install the ECDH keypair 297 provided it wipes knowledge of the private key. Typically, the 298 provisioning service will make the public key (HI) and PSK available 299 for the deployment step. 301 Due to the substantially reduced security guarantees of HIP DEX 302 compared to HIP BEX, HIP DEX MUST only be used when at least one of 303 the two endpoints is a class 0 or 1 constrained device defined in 304 Section 3 of [RFC7228]). HIP DEX MUST NOT be used when both 305 endpoints are class 2 devices or unconstrained. 307 1.3. Memo Structure 309 The rest of this memo is structured as follows. Section 2 defines 310 the central keywords, notation, and terms used throughout this 311 document. Section 3 defines the structure of the Host Identity and 312 its various representations. Section 4 gives an overview of the HIP 313 Diet EXchange protocol. Sections 5 and 6 define the detailed packet 314 formats and rules for packet processing. Finally, Sections 7, 8, 9, 315 and 10 discuss policy, interoperability between HIPv2 vs DEX, 316 security, and IANA considerations, respectively. Appendix A defines 317 a two factor authentication scheme and Appendix B highlights some 318 discussions with the IESG. 320 2. Terms, Notation and Definitions 322 2.1. Requirements Terminology 324 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 325 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 326 "OPTIONAL" in this document are to be interpreted as described in BCP 327 14 [RFC2119] [RFC8174] when, and only when, they appear in all 328 capitals, as shown here. 330 2.2. Notation 332 [x] indicates that x is optional. 334 {x} indicates that x is encrypted. 336 X(y) indicates that y is a parameter of X. 338 i indicates that x exists i times. 340 --> signifies "Initiator to Responder" communication (requests). 342 <-- signifies "Responder to Initiator" communication (replies). 344 | signifies concatenation of information - e.g., X | Y is the 345 concatenation of X and Y. 347 FOLD (X, K) denotes the partitioning of X into n K-bit segments and 348 the iterative folding of these segments via XOR. I.e., X = x_1, 349 x_2, ..., x_n, where x_i is of length K and the last segment x_n 350 is padded to length K by appending 0 bits. FOLD then is computed 351 as FOLD(X, K) = t_n, where t_i = t_i-1 XOR x_i and t_1 = x_1. 353 Ltrunc (M(x), K) denotes the lowest order K bits of the result of 354 the MAC function M on the input x. 356 sort (HIT-I | HIT-R) is defined as the network byte order 357 concatenation of the two HITs, with the smaller HIT preceding the 358 larger HIT, resulting from the numeric comparison of the two HITs 359 interpreted as positive (unsigned) 128-bit integers in network 360 byte order. 362 2.3. Definitions 364 CKDF: CMAC-based Key Derivation Function. 366 CMAC: The Cipher-based Message Authentication Code with the 128-bit 367 Advanced Encryption Standard (AES) defined in [NIST.SP.800-38B]. 369 HIP association: The shared state between two peers after completion 370 of the HIP handshake. 372 HIP DEX (Diet EXchange): The ECDH-based HIP handshake for 373 establishing a new HIP association. 375 HIT Suite: A HIT Suite groups all algorithms that are required to 376 generate and use an HI and its HIT. In particular for HIP DEX, 377 these algorithms are: 1) ECDH and 2) FOLD. 379 HI (Host Identity): The static ECDH public key that represents the 380 identity of the host. In HIP DEX, a host proves ownership of the 381 private key belonging to its HI by creating a HIP_MAC with the 382 derived ECDH key (see Section 3) in the appropriate I2 or R2 383 packet. 385 HIT (Host Identity Tag): A shorthand for the HI in IPv6 format. It 386 is generated by folding the HI (see Section 3). 388 Initiator: The host that initiates the HIP DEX handshake. This role 389 is typically forgotten once the handshake is completed. 391 KEYMAT: Keying material. That is, the bit string(s) used as 392 cryptographic keys. 394 RHASH_len: The natural output length of the RHASH Algorithm in bits. 396 Nonce #I: Nonce #I refers to the corresponding field in the PUZZLE 397 parameter (see section 5.2.4 in [RFC7401]. It is also referred to 398 as "random value #I" in this document. 400 OGA (Orchid Generation Algorithm): Hash function used in generating 401 the ORCHID. 403 ORCHID (Overlay Routable Cryptographic Hash Identifiers): IPv6 404 addresses intended to be used as endpoint identifiers at 405 applications and Application Programming Interfaces (APIs) and not 406 as identifiers for network location at the IP layer. 408 Puzzle difficulty K: The Initiator has to compute a solution for the 409 puzzle. The level of computational difficulty is denoted by the 410 #K field in the puzzle parameter (see section 5.2.4 in [RFC7401]. 412 Responder: The host that responds to the Initiator in the HIP DEX 413 handshake. This role is typically forgotten once the handshake is 414 completed. 416 RHASH (Responder's HIT Hash Algorithm): In HIP DEX, RHASH is 417 redefined as CMAC. Still, note that CMAC is a message 418 authentication code (MAC) and not a cryptographic hash function. 419 Thus, a mapping from CMAC(x,y) to RHASH(z) must be defined where 420 RHASH is used. Moreover, RHASH has different security properties 421 in HIP DEX and is not used for HIT generation. 423 Secure Association (SA): An SA is a simplex "connection" that 424 affords security services to the traffic carried by it. HIP DEX 425 has two forms of SAs, a Master Key SA for the actual HIP traffic, 426 and a Pair-wise Key SA for use by a data transport service. 428 3. Host Identity (HI) and its Structure 430 In this section, the properties of the Host Identity and Host 431 Identity Tag are discussed, and the exact format for them is defined. 432 In HIP, the public key of an asymmetric key pair is used as the Host 433 Identity (HI). Correspondingly, the host itself is defined as the 434 entity that holds the private key of the key pair. See the HIP 435 architecture specification [I-D.ietf-hip-rfc4423-bis] for more 436 details on the difference between an identity and the corresponding 437 identifier. 439 HIP DEX implementations use Elliptic Curve Diffie-Hellman (ECDH) 440 [RFC6090] key exchange for generating the HI as defined in 441 Section 5.2.3. No alternative algorithms are defined at this time. 443 A compressed encoding of the HI, the Host Identity Tag (HIT), is used 444 in the handshake packets to represent the HI. The DEX Host Identity 445 Tag (HIT) is different from the BEX HIT in two ways: 447 o The HIT suite ID MUST only be a DEX HIT ID (see Section 5.2.4). 449 o The DEX HIT is not generated via a cryptographic hash. Rather, it 450 is a compression of the HI. 452 Due to the latter property, an attacker may be able to find a 453 collision with a HIT that is in use. Hence, policy decisions such as 454 access control MUST NOT be based solely on the HIT. Instead, the HI 455 of a host SHOULD be considered (see Section 7.1). 457 Carrying HIs or HITs in the header of user data packets would 458 increase the overhead of packets. Thus, it is not expected that 459 these parameters are carried in every packet, but other methods are 460 used to map the data packets to the corresponding HIs. In some 461 cases, this allows use of HIP DEX without any additional headers in 462 the user data packets. For example, if ESP is used to protect data 463 traffic, the Security Parameter Index (SPI) carried in the ESP header 464 can be used to map the encrypted data packet to the correct HIP DEX 465 association. When other user data packet formats are used, the 466 corresponding extensions need to define a replacement for the 467 ESP_TRANSFORM [RFC7402] parameter along with associated semantics, 468 but this procedure is outside the scope of this document. 470 3.1. Host Identity Tag (HIT) 472 With HIP DEX, the HIT is a 128-bit value - a compression of the HI 473 prepended with a specific prefix. There are two advantages of using 474 this compressed encoding over the actual variable-sized public key in 475 protocols. First, the fixed length of the HIT keeps packet sizes 476 manageable and eases protocol coding. Second, it presents a 477 consistent format for the protocol, independent of the underlying 478 identity technology in use. 480 The structure of the HIT is based on RFC 7343 [RFC7343], called 481 Overlay Routable Cryptographic Hash Identifiers (ORCHIDs), and 482 consists of three parts: first, an IANA assigned prefix to 483 distinguish it from other IPv6 addresses. Second, a four-bit 484 encoding of the algorithms that were used for generating the HI and 485 the compressed representation of the HI. Third, the 96-bit 486 compressed representation of the HI. In contrast to HIPv2, HIP DEX 487 employs HITs that are NOT generated by means of a cryptographic hash. 488 Instead, the HI is compressed to 96 bits as defined in the following 489 section. 491 3.2. Generating a HIT from an HI 493 The HIT does not follow the exact semantics of an ORCHID as there is 494 no hash function in HIP DEX. Still, its structure is strongly 495 aligned with the ORCHID design. The same IPv6 prefix used in HIPv2 496 is used for HIP DEX. The HIP DEX HIT suite (see Section 10) is used 497 for the four bits of the Orchid Generation Algorithm (OGA) field in 498 the ORCHID. The hash representation in an ORCHID is replaced with 499 FOLD(HI,96). 501 3.2.1. Why Introduce FOLD 503 HIP DEX by design lacks a cryptographic hash function. The 504 generation of the HIT is one of the few places in the protocol where 505 this presents a challenge. CMAC was first considered for this 506 purpose, but to use CMAC for HIT generation would require using a 507 static key, either ZERO or some published value. NIST does not 508 consider CMAC an approved cryptographic hash as: 510 It is straightforward to demonstrate that CMAC is not collision- 511 resistant for any choice of a published key. 513 Since collision-resistance is not possible with the tools at hand, 514 any reasonable function (e.g. FOLD) that takes the full value of the 515 HI into generating the HIT can be used, provided that collision 516 detection is part of the HIP-DEX deployment design. This is achieved 517 here through either an ACL or some other lookup process that 518 externally binds the HIT and HI. 520 HIT collisions have always been a statistical possibility in BEX and 521 thus the HI has always been a part of the R1 and I2 packets for HI 522 validation. 524 4. Protocol Overview 526 This section gives a simplified overview of the HIP DEX protocol 527 operation and does not contain all the details of the packet formats 528 or the packet processing steps. Section 5 and Section 6 describe 529 these aspects in more detail and are normative in case of any 530 conflicts with this section. Importantly, the information given in 531 this section focuses on the differences between the HIPv2 and HIP DEX 532 protocol specifications. 534 4.1. Creating a HIP Association 536 By definition, the system initiating a HIP Diet EXchange is the 537 Initiator, and the peer is the Responder. This distinction is 538 typically forgotten once the handshake completes, and either party 539 can become the Initiator in future communications. 541 The HIP Diet EXchange serves to manage the establishment of state 542 between an Initiator and a Responder. The first packet, I1, 543 initiates the exchange, and the last three packets, R1, I2, and R2, 544 constitute an authenticated Diffie-Hellman [DH76] key exchange for 545 the Master Key Security Association (SA) generation. This Master Key 546 SA is used by the Initiator and the Responder to wrap secret keying 547 material in the I2 and R2 packets. Based on the exchanged keying 548 material, the peers then derive a Pair-wise Key SA if cryptographic 549 keys are needed, e.g., for ESP-based protection of user data. 551 The Initiator first sends a trigger packet, I1, to the Responder. 552 This packet contains the HIT of the Initiator and the HIT of the 553 Responder, if it is known. Moreover, the I1 packet initializes the 554 negotiation of the Diffie-Hellman group that is used for generating 555 the Master Key SA by including a list of Diffie-Hellman Group IDs 556 supported by the Initiator. 558 The second packet, R1, starts the actual authenticated Diffie-Hellman 559 key exchange. It contains a puzzle - a cryptographic challenge that 560 the Initiator must solve before continuing the exchange. The level 561 of difficulty of the puzzle can be adjusted based on level of 562 knowledge of the Initiator, current load, or other factors. In 563 addition, the R1 contains the Responder's Diffie-Hellman parameter 564 and lists of cryptographic algorithms supported by the Responder. 565 Based on these lists, the Initiator can continue, abort, or restart 566 the handshake with a different selection of cryptographic algorithms. 568 Unlike in HIP BEX, the R1 packet in DEX is not signed. Thus the 569 Initiator MUST compare the content of R1 with that it later gets in 570 R2 to ensure there was no MITM attack on R1. 572 In the I2 packet, the Initiator MUST display the solution to the 573 received puzzle. Without a correct solution, the I2 packet is 574 discarded. The I2 also contains a nonce and key wrap parameter that 575 carries secret keying material of the Initiator. This keying 576 material is only half of the final session (pair-wise) key. The 577 packet is authenticated by the sender (Initiator) via a MAC. 579 The R2 packet acknowledges the receipt of the I2 packet and completes 580 the handshake. The R2 echos the nonce from I2 and contains a key 581 wrap parameter that carries the rest of the keying material of the 582 Responder. The packet is authenticated by the sender (Responder) via 583 a MAC. The R2 repeats the lists from R1 for signed validation to 584 defend them against a MITM attack. 586 The HIP DEX handshake is illustrated below. The terms "ENC(DH,x)" 587 and "ENC(DH,y)" refer to the random values x and y that are wrapped 588 based on the Master Key SA (indicated by ENC and DH). Note that x 589 and y each constitute half of the final session key material. The 590 packets also contain other parameters that are not shown in this 591 figure. 593 Initiator Responder 595 I1: DH List 596 --------------------------------------> 598 remain stateless 600 R1: puzzle, (DH, Suite, Trans) Lists, 601 HI 602 <------------------------------------- 604 solve puzzle 605 perform ECDH 606 encrypt x 608 I2: solution, HI, ENC(DH,x), Trans List, 609 I_Nonce, mac 610 --------------------------------------> 612 check puzzle 613 perform ECDH 614 check MAC 615 decrypt x 616 encrypt y 618 R2: (DH, Suite, Trans) Lists, ENC(DH,y), 619 I_Nonce, mac 620 <-------------------------------------- 622 check MAC 623 validate lists in R1 624 decrypt y 626 Figure 1: High-level overview of the HIP Diet EXchange 628 4.1.1. HIP Puzzle Mechanism 630 The purpose of the HIP puzzle mechanism is to protect the Responder 631 from a number of denial-of-service threats. It allows the Responder 632 to delay state creation until receiving the I2 packet. Furthermore, 633 the puzzle allows the Responder to use a fairly cheap calculation to 634 check that the Initiator is "sincere" in the sense that it has 635 churned enough CPU cycles in solving the puzzle. 637 The puzzle mechanism enables a Responder to immediately reject an I2 638 packet if it does not contain a valid puzzle solution. To verify the 639 puzzle solution, the Responder only has to compute a single CMAC 640 operation. After a successful puzzle verification, the Responder can 641 securely create session-specific state and perform CPU-intensive 642 operations such as a Diffie-Hellman key generation. By varying the 643 difficulty of the puzzle, the Responder can frustrate CPU or memory 644 targeted DoS attacks. Under normal network conditions, the puzzle 645 difficulty SHOULD be zero, thus effectively reverting the puzzle 646 mechanism to a cookie-based DoS protection mechanism. Without 647 setting the puzzle difficulty to zero under normal network 648 conditions, potentially scarce computation resources at the Initiator 649 would be churned unnecessarily. 651 Conceptually, the puzzle mechanism in HIP DEX is the same as in 652 HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in 653 [RFC7401] for more detailed information about the employed mechanism. 654 Notably, the only differences between the puzzle mechanism in HIP DEX 655 and HIPv2 are that HIP DEX does not employ pre-computation of R1 656 packets and uses CMAC instead of a hash function for solving and 657 verifying a puzzle. The implications of these changes on the puzzle 658 implementation are discussed in Section 6.1. 660 4.1.2. HIP State Machine 662 The HIP DEX state machine has the same states as the HIPv2 state 663 machine (see Section 4.4. in [RFC7401]); this is for easier 664 comparison between the two Exchanges. However, HIP DEX features a 665 retransmission strategy with an optional reception acknowledgement 666 for the I2 packet. The goal of this additional acknowledgement is to 667 reduce premature I2 retransmissions in case of devices with low 668 computation resources [HWZ13]. As a result, there are minor changes 669 regarding the transitions in the HIP DEX state machine. The 670 following section documents these differences compared to HIPv2. 672 4.1.2.1. HIP DEX Retransmission Mechanism 674 For the retransmission of I1 and I2 packets, the Initiator adopts the 675 retransmission strategy of HIPv2 (see Section 4.4.3. in [RFC7401]). 676 This strategy is based on a timeout that is set to a value larger 677 than the worst-case anticipated round-trip time (RTT). For each 678 received I1 or I2 packet, the Responder sends an R1 or R2 packet, 679 respectively. This design trait to always send an R1 after an I1 680 enables the Responder to remain stateless until the reception and 681 successful processing of the I2 packet. The Initiator stops 682 retransmitting I1 or I2 packets after the reception of the 683 corresponding R1 or R2. If the Initiator did not receive an R1 684 packet after I1_RETRIES_MAX tries, it stops I1 retransmissions. 685 Likewise, it stops retransmitting the I2 packet after I2_RETRIES_MAX 686 unsuccessful tries. 688 For repeatedly received I2 packets, the Responder SHOULD NOT perform 689 operations related to the Diffie-Hellman key exchange or the keying 690 material wrapped in the ENCRYPTED_KEY parameters. Instead, it SHOULD 691 re-use the previously established state to re-create the 692 corresponding R2 packet in order to prevent unnecessary computation 693 overhead. 695 The potentially high processing time of an I2 packet at a (resource- 696 constrained) Responder may cause premature retransmissions if the 697 time required for I2 transmission and processing exceeds the RTT- 698 based retransmission timeout. Thus, the Initiator should also take 699 the processing time of the I2 packet at the Responder into account 700 for retransmission purposes. To this end, the Responder MAY notify 701 the Initiator about the anticipated delay once the puzzle solution 702 was successfully verified that the remaining I2 packet processing 703 will incur a high processing delay. The Responder MAY therefore send 704 a NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator 705 before the Responder commences the ECDH operation. The NOTIFY packet 706 serves as an acknowledgement for the I2 packet and consists of a 707 NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT 708 (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter 709 contains the anticipated remaining processing time for the I2 packet 710 in milliseconds as two-octet Notification Data. This processing time 711 can, e.g., be estimated by measuring the computation time of the ECDH 712 key derivation operation during the Responder start-up procedure. 713 After the I2 processing has finished, the Responder sends the regular 714 R2 packet. 716 When the Initiator receives the NOTIFY packet, it sets the I2 717 retransmission timeout to the I2 processing time indicated in the 718 NOTIFICATION parameter plus half the RTT-based timeout value. In 719 doing so, the Initiator MUST NOT set the retransmission timeout to a 720 higher value than allowed by a local policy. This is to prevent 721 unauthenticated NOTIFY packets from maliciously delaying the 722 handshake beyond a well-defined upper bound in case of a lost R2 723 packet. At the same time, this extended retransmission timeout 724 enables the Initiator to defer I2 retransmissions until the point in 725 time when the Responder should have completed its I2 packet 726 processing and the network should have delivered the R2 packet 727 according to the employed worst-case estimates. 729 4.1.2.2. HIP State Processes 731 HIP DEX clarifies or introduces the following new transitions. 733 System behavior in state I2-SENT, Table 1. 735 +---------------------+---------------------------------------------+ 736 | Trigger | Action | 737 +---------------------+---------------------------------------------+ 738 | Receive NOTIFY, | Set I2 retransmission timer to value in | 739 | process | I2_ACKNOWLEDGEMENT Notification Data plus | 740 | | 1/2 RTT-based timeout value and stay at | 741 | | I2-SENT | 742 | | | 743 | | | 744 | | | 745 | Timeout | Increment trial counter | 746 | | | 747 | | | 748 | | | 749 | | If counter is less than I2_RETRIES_MAX, | 750 | | send I2, reset timer to RTT-based timeout, | 751 | | and stay at I2-SENT | 752 | | | 753 | | | 754 | | | 755 | | If counter is greater than I2_RETRIES_MAX, | 756 | | go to E-FAILED | 757 +---------------------+---------------------------------------------+ 759 Table 1: I2-SENT - Waiting to finish the HIP Diet EXchange 761 4.1.2.3. Simplified HIP State Diagram 763 The following diagram shows the major state transitions. Transitions 764 based on received packets implicitly assume that the packets are 765 successfully authenticated or processed. 767 +--+ +----------------------------+ 768 recv I1, send R1 | | | | 769 | v v | 770 +--------------+ recv I2, send R2 | 771 +----------------| UNASSOCIATED |----------------+ | 772 datagram | +--+ +--------------+ | | 773 to send, | | | Alg. not supported, | | 774 send I1 | | | send I1 | | 775 . v | v | | 776 . +---------+ recv I2, send R2 | | 777 +---->| I1-SENT |--------------------------------------+ | | 778 | +---------+ +----------------------+ | | | 779 | | recv R1, | recv I2, send R2 | | | | 780 | v send I2 | v v v | 781 | +---------+----------+ +---------+ | 782 | +--->| I2-SENT |<-------------+ +------------| R2-SENT |<---+ | 783 | | +---------+ recv NOTIFY, | | +---------+ | | 784 | | | | | reset timer | | data or| | | 785 | |recv R1, | | +--------------+ | EC timeout| | | 786 | |send I2 +-|--------------------+ | receive I2,| | 787 | | | | +-------------+ | send R2| | 788 | | | +-------->| ESTABLISHED |<---------+ | | 789 | | | recv R2 +-------------+ | | 790 | | | | | | receive I2, send R2 | | 791 | | +------------+ | +-------------------------------+ | 792 | | | +-----------+ | | 793 | | | no packet sent/received| +---+ | | 794 | | | for UAL min, send CLOSE| | |timeout | | 795 | | | v v |(UAL+MSL) | | 796 | | | +---------+ |retransmit | | 797 +--|----------|------------------------| CLOSING |-+CLOSE | | 798 | | +---------+ | | 799 | | | | | | | | 800 +----------|-------------------------+ | | +----------------+ | 801 | | +-----------+ +------------------|--+ 802 | | |recv CLOSE, recv CLOSE_ACK | | 803 | +-------------+ |send CLOSE_ACK or timeout | | 804 | recv CLOSE, | | (UAL+MSL) | | 805 | send CLOSE_ACK v v | | 806 | +--------+ receive I2, send R2 | | 807 +---------------------| CLOSED |------------------------------+ | 808 +--------+ | 809 ^ | | | 810 recv CLOSE, send CLOSE_ACK| | | timeout (UAL+2MSL) | 811 +-+ +------------------------------------+ 813 4.1.3. HIP DEX Security Associations 815 HIP DEX establishes two Security Associations (SA), one for the 816 Diffie-Hellman derived key, or Master Key, and one for the session 817 key, or Pair-wise Key. 819 4.1.3.1. Master Key SA 821 The Master Key SA is used to authenticate HIP packets and to encrypt 822 selected HIP parameters in the HIP DEX packet exchanges. Since only 823 a small amount of data is protected by this SA, it can be long-lived 824 with no need for rekeying. At the latest, the system MUST initiate 825 rekeying when its incoming ESP sequence counter is going to overflow, 826 and the system MUST NOT replace its keying material until the 827 rekeying packet exchange successfully completes as described in 828 Section 6.8 in [RFC7402]. 830 The Master Key SA contains the following elements: 832 o Source HIT 834 o Destination HIT 836 o HIP_Encrypt Key 838 o HIP_MAC Key 840 The HIP_Encrypt and HIP_MAC keys are extracted from the Diffie- 841 Hellman derived key as described in Section 6.3. Their length is 842 determined by the HIP_CIPHER. 844 4.1.3.2. Pair-wise Key SA 846 The Pair-wise Key SA is used to authenticate and to encrypt user 847 data. It is refreshed (or rekeyed) using an UPDATE packet exchange. 848 The Pair-wise Key SA elements are defined by the data transform 849 (e.g., ESP_TRANSFORM [RFC7402]). 851 The keys for the Pair-wise Key SA are derived based on the wrapped 852 keying material exchanged in the ENCRYPTED_KEY parameter (see 853 Section 5.2.5) of the I2 and R2 packets. Specifically, the exchanged 854 keying material of the two peers is concatenated. This concatenation 855 forms the input to a Key Derivation Function (KDF). If the data 856 transform does not specify its own KDF, the key derivation function 857 defined in Section 6.3 is used. Even though the concatenated input 858 is randomly distributed, a KDF Extract phase may be needed to get the 859 proper length for the input to the KDF Expand phase. 861 4.1.4. User Data Considerations 863 The User Data Considerations in Section 4.5. of [RFC7401] also apply 864 to HIP DEX. There is only one difference between HIPv2 and HIP DEX. 865 Loss of state due to system reboot may be a critical performance 866 issue for resource-constrained devices. Thus, implementors MAY 867 choose to use non-volatile, secure storage for HIP states in order 868 for them to survive a system reboot as discussed in Section 6.11. 869 Using non-volatile storage will limit state loss during reboots to 870 only those situations with an SA timeout. 872 5. Packet Formats 874 5.1. Payload Format 876 HIP DEX employs the same fixed HIP header and payload structure as 877 HIPv2. As such, the specifications in Section 5.1 of [RFC7401] also 878 apply to HIP DEX. 880 5.2. HIP Parameters 882 The HIP parameters carry information that is necessary for 883 establishing and maintaining a HIP association. For example, the 884 peer's public keys as well as the signaling for negotiating ciphers 885 and payload handling are encapsulated in HIP parameters. Additional 886 information, meaningful for end-hosts or middleboxes, may also be 887 included in HIP parameters. The specification of the HIP parameters 888 and their mapping to HIP packets and packet types is flexible to 889 allow HIP extensions to define new parameters and new protocol 890 behavior. 892 In HIP packets, HIP parameters are ordered according to their numeric 893 type number and encoded in TLV format. 895 HIP DEX reuses the HIP parameters of HIPv2 defined in Section 5.2. of 896 [RFC7401] where possible. Still, HIP DEX further restricts and/or 897 extends the following existing parameter types: 899 o DH_GROUP_LIST and HOST_ID are restricted to ECC-based suites. 901 o HIP_CIPHER is restricted to AES-128-CTR. 903 o HIT_SUITE_LIST is limited to the HIT suite ECDH/FOLD. 905 o PUZZLE, SOLUTION, and HIP_MAC parameter processing is altered to 906 support CMAC in RHASH and RHASH_len (see Section 6.1 and 907 Section 6.2). 909 In addition, HIP DEX introduces the following new parameters: 911 +------------------+--------------+----------+----------------------+ 912 | TLV | Type | Length | Data | 913 +------------------+--------------+----------+----------------------+ 914 | ENCRYPTED_KEY | TBD1 | variable | Encrypted container | 915 | | (suggested | | for the session key | 916 | | value 643) | | exchange | 917 | | | | | 918 | I_NONCE | TBD6 | variable | Nonce from Initator | 919 | | (suggested | | for Master Key | 920 | | value 644) | | | 921 +------------------+--------------+----------+----------------------+ 923 5.2.1. DH_GROUP_LIST 925 The DH_GROUP_LIST parameter contains the list of supported DH Group 926 IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With 927 HIP DEX, the DH Group IDs are restricted to: 929 Group KDF Value 931 NIST P-256 [RFC5903] CKDF 7 932 NIST P-384 [RFC5903] CKDF 8 934 Curve25519 [RFC7748] CKDF TBD7 (suggested value 12) 935 Curve448 [RFC7748] CKDF TBD8 (suggested value 13) 937 The ECDH groups with values 7 - 9 are defined in [RFC5903] and 938 [RFC6090]. These curves, when used with HIP MUST have a co-factor of 939 1. 941 The ECDH groups with values TBD7 and TBD8 are defined in [RFC7748]. 942 These curves have cofactors of 8 and 4 (respectively). 944 5.2.2. HIP_CIPHER 946 The HIP_CIPHER parameter contains the list of supported cipher 947 algorithms to be used for encrypting the contents of the ENCRYPTED 948 and ENCRYPTED_KEY parameters. The HIP_CIPHER parameter is defined in 949 Section 5.2.8 of [RFC7401]. With HIP DEX, the Suite IDs are limited 950 to: 952 Suite ID Value 954 RESERVED 0 956 AES-128-CTR TBD4 (suggested: 5) ([RFC3686]) 957 Mandatory implementation: AES-128-CTR. 959 The initialization vector (IV) counter for AES-128-CTR MUST have a 960 length of 128 bits. The puzzle value #I and the puzzle solution #J 961 (see Section 4.1.2 in [RFC7401]) are used to construct the high-order 962 bits of the IV. The IV is computed as FOLD(I | J, 112) plus a 16 bit 963 counter value, which is initialized to zero on first use, appended to 964 the Fold value in order to guarantee that a non-repeating nonce is 965 fed to the AES-CTR encryption algorithm. 967 This IV counter is incremented as it is used for all encrypted HIP 968 parameters. That is a single AES-129-CTR counter associated with the 969 Master Key SA. 971 5.2.3. HOST_ID 973 The HOST_ID parameter conveys the Host Identity (HI) along with 974 optional information about a host. The HOST_ID parameter is defined 975 in Section 5.2.9 of [RFC7401]. 977 HIP DEX uses the public portion of a host's static ECDH key-pair as 978 the HI. Correspondingly, HIP DEX limits the HI algorithms to the 979 following new profile: 981 Algorithm profiles Value 983 ECDH TBD5 (suggested: 11) [RFC6090] (REQUIRED) 985 For hosts that implement ECDH as the algorithm, the following curves 986 are required: 988 Group Value 990 NIST P-256 1 [RFC5903] 991 NIST P-384 2 [RFC5903] 993 Curve25519 5 [RFC7748] 994 Curve448 6 [RFC7748] 996 HIP DEX HIs are serialized equally to the ECC-based HIs in HIPv2 (see 997 Section 5.2.9. of [RFC7401]). The Group ID of the HIP DEX HI is 998 encoded in the "ECC curve" field of the HOST_ID parameter. The 999 supported DH Group IDs are defined in Section 5.2.1. 1001 5.2.4. HIT_SUITE_LIST 1003 The HIT_SUITE_LIST parameter contains a list of the supported HIT 1004 suite IDs of the Responder. Based on the HIT_SUITE_LIST, the 1005 Initiator can determine which source HIT Suite IDs are supported by 1006 the Responder. The HIT_SUITE_LIST parameter is defined in 1007 Section 5.2.10 of [RFC7401]. 1009 The following new HIT Suite ID is defined for HIP DEX, and the 1010 relationship between the four-bit ID value used in the OGA ID field 1011 and the eight-bit encoding within the HIT_SUITE_LIST ID field is 1012 clarified: 1014 HIT Suite Four-bit ID Eight-bit encoding 1016 ECDH/FOLD TBD2 (suggestion: 4) TBD3 (suggestion: 0x40) 1018 Note that the dedicated HIP DEX HIT Suite ID in the OGA ID field 1019 allows the peers to distinguish a HIP DEX handshake from a HIPv2 1020 handshake. The Responder MUST respond with a HIP DEX HIT suite ID 1021 when the HIT of the Initiator is a HIP DEX HIT. 1023 5.2.5. ENCRYPTED_KEY 1025 0 1 2 3 1026 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 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Type | Length | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 / Encrypted value / 1031 / / 1032 / +-------------------------------+ 1033 / | Padding | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 Type TBD1 (suggested value 643) 1037 Length length in octets, excluding Type, Length, and 1038 Padding 1039 Encrypted The value is encrypted using an encryption algorithm 1040 value as defined in the HIP_CIPHER parameter. 1042 The ENCRYPTED_KEY parameter encapsulates a random value that is later 1043 used in the session key creation process (see Section 6.3). This 1044 random value MUST have a length of at least 64 bits. The HIP_CIPHER 1045 is used for the encryption. 1047 Once this encryption process is completed, the "encrypted value" data 1048 field is ready for inclusion in the Parameter. If necessary, 1049 additional Padding for 8-byte alignment is then added according to 1050 the rules of TLV Format in [RFC7401]. 1052 5.2.6. I_NONCE 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Type | Length | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 / Initiator Nonce / 1060 / / 1061 / +-------------------------------+ 1062 / | Padding | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 Type TBD6 (suggested value 644) 1066 Length length in octets, excluding Type, Length, and 1067 Padding 1068 Initiator Nonce provided by the Initiator for use in the 1069 Nonce Master Key 1071 The I_NONCE parameter encapsulates a random value that is later used 1072 in the Master key creation process (see Section 6.3). This random 1073 value MUST have a length of 2 x RHASH_len. This parameter is sent to 1074 the Responder in I2 which echos it back to the Initiator in R2. 1076 If necessary, additional Padding for 8-byte alignment is added 1077 according to the rules of TLV Format in [RFC7401]. 1079 5.3. HIP Packets 1081 HIP DEX uses the same eight basic HIP packets as HIPv2 (see 1082 Section 5.3 of [RFC7401]). Four of them are for the HIP handshake 1083 (I1, R1, I2, and R2), one is for updating an association (UPDATE), 1084 one is for sending notifications (NOTIFY), and two are for closing 1085 the association (CLOSE and CLOSE_ACK). There are some differences 1086 regarding the HIP parameters that are included in the handshake 1087 packets concerning HIP BEX and HIP DEX. This section covers these 1088 differences for the DEX packets. Packets not discussed here, follow 1089 the structure defined in [RFC7401]. 1091 An important difference between packets in HIP BEX and HIP DEX is 1092 that the DIFFIE_HELLMAN and the HIP_SIGNATURE parameters are not 1093 included in HIP DEX. Thus, the R1 packet is completely unprotected 1094 and can be spoofed. As a result, negotiation parameters contained in 1095 the R1 packet have to be re-included in later, protected packets in 1096 order to detect and prevent potential downgrading attacks. Moreover, 1097 the I2, R2, UPDATE, NOTIFY, CLOSE, and CLOSE_ACK packets are not 1098 covered by a signature and purely rely on the HIP_MAC parameter for 1099 packet authentication. The processing of these packets is changed 1100 accordingly. 1102 In the future, an optional upper-layer payload MAY follow the HIP 1103 header. The Next Header field in the header indicates if there is 1104 additional data following the HIP header. 1106 5.3.1. I1 - the HIP Initiator Packet 1108 The HIP header values for the I1 packet: 1110 Header: 1111 Packet Type = 1 1112 SRC HIT = Initiator's HIT 1113 DST HIT = Responder's HIT, or NULL 1115 IP ( HIP ( DH_GROUP_LIST ) ) 1117 Valid control bits: none 1119 The I1 packet contains the fixed HIP header and the Initiator's 1120 DH_GROUP_LIST. The Initiator's HIT Suite ID MUST be of a HIP DEX 1121 type as defined in Section 5.2.4. 1123 Regarding the Responder's HIT, the Initiator may receive this HIT 1124 either from a DNS lookup of the Responder's FQDN (see [RFC8005]), 1125 from some other repository, or from a local table. The Responder's 1126 HIT also MUST be of a HIP DEX type. If the Initiator does not know 1127 the Responder's HIT, it may attempt to use opportunistic mode by 1128 using NULL (all zeros) as the Responder's HIT. See Section 4.1.8 of 1129 [RFC7401] for detailed information about the "HIP Opportunistic 1130 Mode". 1132 As the Initiator's and the Responder's HITs are compressions of the 1133 employed HIs, they determine the DH Group ID that must be used in 1134 order to successfully conclude the triggered handshake. HITs, 1135 however, only include the OGA ID identifying the HI algorithm. They 1136 do not include information about the specific group ID of the HI. To 1137 inform the Responder about its employed and its otherwise supported 1138 DH Group IDs, the Initiator therefore includes the DH_GROUP_LIST 1139 parameter in the I1 packet. This parameter MUST include the DH group 1140 ID that corresponds to the currently employed Initiator HIT as the 1141 first list element. With HIP DEX, the DH_GROUP_LIST parameter MUST 1142 only include ECDH groups defined in Section 5.2.1. 1144 Since this packet is so easy to spoof even if it were protected, no 1145 attempt is made to add to its generation or processing cost. As a 1146 result, the DH_GROUP_LIST in the I1 packet is not protected. 1148 Implementations MUST be able to handle a storm of received I1 1149 packets, discarding those with common content that arrive within a 1150 small time delta. 1152 5.3.2. R1 - the HIP Responder Packet 1154 The HIP header values for the R1 packet: 1156 Header: 1157 Packet Type = 2 1158 SRC HIT = Responder's HIT 1159 DST HIT = Initiator's HIT 1161 IP ( HIP ( [ R1_COUNTER, ] 1162 PUZZLE, 1163 DH_GROUP_LIST, 1164 HIP_CIPHER, 1165 HOST_ID, 1166 HIT_SUITE_LIST, 1167 TRANSPORT_FORMAT_LIST, 1168 [ <, ECHO_REQUEST_UNSIGNED >i ]) 1170 Valid control bits: none 1172 The Initiator's HIT MUST match the one received in the I1 packet if 1173 the R1 is a response to an I1. If the Responder has multiple HIs, 1174 the Responder's HIT MUST match the Initiator's request. If the 1175 Initiator used opportunistic mode, the Responder may select among its 1176 HIs as described below. See Section 4.1.8 of [RFC7401] for detailed 1177 information about the "HIP Opportunistic Mode". 1179 The R1 packet generation counter is used to determine the currently 1180 valid generation of puzzles. The value is increased periodically, 1181 and it is RECOMMENDED that it is increased at least as often as 1182 solutions to old puzzles are no longer accepted. 1184 The Puzzle contains a Random value #I and the puzzle difficulty K. 1185 The difficulty K indicates the number of lower-order bits, in the 1186 puzzle CMAC result, that MUST be zeros (see [RFC7401]). Responders 1187 SHOULD set K to zero by default and only increase the puzzle 1188 difficulty to protect against a DoS attack targeting the HIP DEX 1189 handshake. A puzzle difficulty of zero effectively turns the puzzle 1190 mechanism into a return-routability test and is strongly encouraged 1191 during normal operation in order to conserve energy resources as well 1192 as to prevent unnecessary handshake delay in case of a resource- 1193 constrained Initiator. Please also refer to Section 7 for further 1194 recommendations on choosing puzzle difficulty. 1196 The HIP_CIPHER contains the encryption algorithms supported by the 1197 Responder to protect the key exchange, in the order of preference. 1198 All implementations MUST support the AES-CTR [RFC3686]. 1200 The DH_GROUP_LIST parameter contains the Responder's order of 1201 preference based on the Responder's choice the ECDH key contained in 1202 the HOST_ID parameter (see below). This allows the Initiator to 1203 begin to determine whether its own DH_GROUP_LIST in the I1 packet was 1204 manipulated by an attacker. There is a further risk that the 1205 Responder's DH_GROUP_LIST was manipulated by an attacker, as the R1 1206 packet cannot be authenticated in HIP DEX. Thus, this parameter is 1207 repeated in the R2 packet to allow for a final, cryptographically 1208 secured validation. 1210 The HIT_SUITE_LIST parameter is an ordered list of the Responder's 1211 supported and preferred HIT Suites. It enables a Responder to notify 1212 the Initiator about other available HIT suites than the one used in 1213 the current handshake. Based on the received HIT_SUITE_LIST, the 1214 Initiator MAY decide to abort the current handshake and initiate a 1215 new handshake with a different mutually supported HIT suite. This 1216 mechanism can, e.g., be used to move from an initial HIP DEX 1217 handshake to a HIP BEX handshake for peers supporting both protocol 1218 variants. 1220 The HOST_ID parameter depends on the received DH_GROUP_LIST parameter 1221 and the Responder HIT in the I1 packet. Specifically, if the I1 1222 contains a Responder HIT, the Responder verifies that this HIT 1223 matches the preferred DH group based on the received DH_GROUP_LIST 1224 parameter included in the I1. In case of a positive result, the 1225 Responder selects the corresponding HOST_ID for inclusion in the R1 1226 packet. Likewise, if the Responder HIT in the I1 packet is NULL 1227 (i.e., during an opportunistic handshake), the Responder chooses its 1228 HOST_ID according to the Initiator's employed DH group as indicated 1229 in the received DH_GROUP_LIST parameter and sets the source HIT in 1230 the R1 packet accordingly. If the Responder however does not support 1231 the DH group required by the Initiator or if the Responder HIT in the 1232 I1 packet does not match the required DH group, the Responder selects 1233 the mutually preferred and supported DH group based on the 1234 DH_GROUP_LIST parameter in the I1 packet. The Responder then 1235 includes the corresponding ECDH key in the HOST_ID parameter. This 1236 parameter also indicates the selected DH group. Moreover, the 1237 Responder sets the source HIT in the R1 packet based on the 1238 destination HIT from the I1 packet. Based on the deviating DH group 1239 ID in the HOST_ID parameter, the Initiator then MUST abort the 1240 current handshake and SHOULD initiate a new handshake with the 1241 mutually supported DH group as far as local policies (see Section 7) 1242 permit. 1244 The TRANSPORT_FORMAT_LIST parameter is an ordered list of the 1245 Responder's supported and preferred transport format types. The list 1246 allows the Initiator and the Responder to agree on a common type for 1247 payload protection. The different format types are DEFAULT, ESP 1248 (Mandatory to Implement) and ESP-TCP (Experimental, as explained in 1249 Section 3.1 in [RFC6261]). 1251 The ECHO_REQUEST_UNSIGNED parameters contain data that the sender 1252 wants to receive unmodified in the corresponding response packet in 1253 the ECHO_RESPONSE_UNSIGNED parameter. The R1 packet may contain zero 1254 or more ECHO_REQUEST_UNSIGNED parameters. 1256 5.3.3. I2 - the Second HIP Initiator Packet 1258 The HIP header values for the I2 packet: 1260 Header: 1261 Type = 3 1262 SRC HIT = Initiator's HIT 1263 DST HIT = Responder's HIT 1265 IP ( HIP ( [R1_COUNTER,] 1266 SOLUTION, 1267 HIP_CIPHER, 1268 ENCRYPTED_KEY, 1269 HOST_ID, 1270 TRANSPORT_FORMAT_LIST, 1271 I_NONCE, 1272 HIP_MAC 1273 [<, ECHO_RESPONSE_UNSIGNED>i )] ) 1275 Valid control bits: none 1277 The HITs MUST match the ones used in the R1 packet. 1279 If present in the R1 packet, the Initiator MUST include an unmodified 1280 copy of the R1_COUNTER parameter into the I2 packet. 1282 The Solution contains the Random #I from the R1 packet and the 1283 computed #J value. The low-order #K bits of the RHASH(I | ... | J) 1284 MUST be zero. 1286 The HIP_CIPHER contains the single encryption transform selected by 1287 the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY 1288 parameters. The chosen cipher MUST correspond to one of the ciphers 1289 offered by the Responder in the R1. All implementations MUST support 1290 the AES-CTR transform [RFC3686]. 1292 The HOST_ID parameter contains the Initiator HI corresponding to the 1293 Initiator HIT. 1295 The ENCRYPTED_KEY parameter contains an Initiator generated random 1296 value that MUST be uniformly distributed. This random value is 1297 encrypted with the Master Key SA using the HIP_CIPHER encryption 1298 algorithm. 1300 The ECHO_RESPONSE_UNSIGNED parameter(s) contain the unmodified Opaque 1301 data copied from the corresponding echo request parameter(s). This 1302 parameter can also be used for two-factor password authentication as 1303 shown in Appendix A. 1305 The TRANSPORT_FORMAT_LIST parameter contains the single transport 1306 format type selected by the Initiator. The chosen type MUST 1307 correspond to one of the types offered by the Responder in the R1 1308 packet. The different format types are DEFAULT, ESP and ESP-TCP as 1309 explained in Section 3.1 in [RFC6261]. 1311 The I_NONCE parameter contains the nonce, supplied by the Initiator 1312 for the Master Key generation as shown in Section 6.3. This is 1313 echoed back to the Initiator in the R2 packet. 1315 The MAC is calculated over the whole HIP envelope, excluding any 1316 parameters after the HIP_MAC parameter as described in Section 6.2. 1317 The Responder MUST validate the HIP_MAC parameter. 1319 5.3.4. R2 - the Second HIP Responder Packet 1321 The HIP header values for the R2 packet: 1323 Header: 1324 Packet Type = 4 1325 SRC HIT = Responder's HIT 1326 DST HIT = Initiator's HIT 1328 IP ( HIP ( DH_GROUP_LIST, 1329 HIP_CIPHER, 1330 ENCRYPTED_KEY, 1331 HIT_SUITE_LIST, 1332 TRANSPORT_FORMAT_LIST, 1333 I_NONCE, 1334 HIP_MAC) 1336 Valid control bits: none 1338 The HITs used MUST match the ones used in the I2 packet. 1340 The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, 1341 and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These 1342 parameters MUST be the same as included in the R1 packet. The 1343 parameter are re-included here because the R2 packet is MACed and 1344 thus cannot be altered by an attacker. For verification purposes, 1345 the Initiator re-evaluates the selected suites and compares the 1346 results against the chosen ones. If the re-evaluated suites do not 1347 match the chosen ones, the Initiator acts based on its local policy. 1349 The ENCRYPTED_KEY parameter contains an Responder generated random 1350 value that MUST be uniformly distributed. This random value is 1351 encrypted with the Master Key SA using the HIP_CIPHER encryption 1352 algorithm. 1354 The I_NONCE parameter contains the nonce, supplied by the Initiator 1355 for the Master Key generation as shown in Section 6.3. The Responder 1356 is echoing the value back to the Initiator to show it used the 1357 Initiator provided nonce. 1359 The MAC is calculated over the whole HIP envelope, excluding any 1360 parameters after the HIP_MAC, as described in Section 6.2. The 1361 Initiator MUST validate the HIP_MAC parameter. 1363 5.4. ICMP Messages 1365 When a HIP implementation detects a problem with an incoming packet, 1366 and it either cannot determine the identity of the sender of the 1367 packet or does not have any existing HIP association with the sender 1368 of the packet, it MAY respond with an ICMP packet. Any such reply 1369 MUST be rate-limited as described in [RFC4443]. In most cases, the 1370 ICMP packet has the Parameter Problem type (12 for ICMPv4, 4 for 1371 ICMPv6) and Code of 0. The Pointer field pointing to the field that 1372 caused the ICMP message to be generated, for example to the first 8 1373 bytes of a UDP payload for "SPI is Unknown". The problem cases 1374 specified in Section 5.4. of [RFC7401] also apply to HIP DEX. 1376 6. Packet Processing 1378 Due to the adopted protocol semantics and the inherited general 1379 packet structure, the packet processing in HIP DEX only differs from 1380 HIPv2 in very few places. Here, we focus on these differences and 1381 refer to Section 6 in [RFC7401] otherwise. 1383 The processing of outgoing and incoming application data remains the 1384 same as in HIP BEX (see Sections 6.1 and 6.2 in [RFC7401]). 1386 6.1. Solving the Puzzle 1388 The procedures for solving and verifying a puzzle in HIP DEX are 1389 strongly based on the corresponding procedures in HIPv2. The only 1390 exceptions are that HIP DEX does not use pre-computation of R1 1391 packets and that RHASH is set to CMAC. As a result, the pre- 1392 computation step in Section 6.3 of [RFC7401] is skipped in HIP DEX. 1394 Moreover, the Initiator solves a puzzle by computing: 1395 Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) == 0 1397 Similarly, the Responder verifies a puzzle by computing: 1398 V := Ltrunc( CMAC( I, HIT-I | HIT-R | J ), K ) 1400 Apart from these modifications, the procedures defined in Section 6.3 1401 of [RFC7401] also apply for HIP DEX. 1403 6.2. HIP_MAC Calculation and Verification 1405 The following subsections define the actions for processing the 1406 HIP_MAC parameter. 1408 6.2.1. CMAC Calculation 1410 The HIP_MAC calculation uses RHASH, i.e., CMAC, as the underlying 1411 cryptographic function. The scope of the calculation for HIP_MAC is: 1413 CMAC: { HIP header | [ Parameters ] } 1415 where Parameters include all HIP parameters of the packet that is 1416 being calculated with Type values ranging from 1 to (HIP_MAC's Type 1417 value - 1) and exclude parameters with Type values greater or equal 1418 to HIP_MAC's Type value. 1420 During HIP_MAC calculation, the following applies: 1422 o In the HIP header, the Checksum field is set to zero. 1424 o In the HIP header, the Header Length field value is calculated to 1425 the beginning of the HIP_MAC parameter. 1427 The parameter order is described in Section 5.2.1 of [RFC7401]. 1429 The CMAC calculation and verification process is as follows: 1431 Packet sender: 1433 1. Create the HIP packet, without the HIP_MAC or any other parameter 1434 with greater Type value than the HIP_MAC parameter has. 1436 2. Calculate the Header Length field in the HIP header. 1438 3. Compute the CMAC using either HIP-gl or HIP-lg integrity key 1439 retrieved from KEYMAT as defined in Section 6.3. HIP-gl refers 1440 to host with greater HIT value and HIP-lg refers to the host with 1441 smaller HIT value. 1443 4. Add the HIP_MAC parameter to the packet and any parameter with 1444 greater Type value than the HIP_MAC's that may follow. 1446 5. Recalculate the Length field in the HIP header. 1448 Packet receiver: 1450 1. Verify the HIP header Length field. 1452 2. Remove the HIP_MAC parameter, as well as all other parameters 1453 that follow it with greater Type value, saving the contents if 1454 they will be needed later. 1456 3. Recalculate the HIP packet length in the HIP header and clear the 1457 Checksum field (set it to all zeros). 1459 4. Compute the CMAC using either HIP-gl or HIP-lg integrity key as 1460 defined in Section 6.3 and verify it against the received CMAC. 1462 5. Set Checksum and Header Length fields in the HIP header to 1463 original values. Note that the Checksum and Length fields 1464 contain incorrect values after this step. 1466 6.3. HIP DEX KEYMAT Generation 1468 The HIP DEX KEYMAT process is used to derive the keys for the Master 1469 Key SA as well as for the Pair-wise Key SA. The keys for the Master 1470 Key SA are based on the Diffie-Hellman derived key, Kij, which is 1471 produced during the HIP DEX handshake. The Initiator generates Kij 1472 during the creation of the I2 packet and the Responder generates Kij 1473 once it receives the I2 packet. This is why the I2 packet can 1474 already contain authenticated and/or encrypted information. 1476 The keys derived for the Pair-wise Key SA are not used during the HIP 1477 DEX handshake. Instead, these keys are made available as payload 1478 protection keys (e.g., for IPsec). 1480 The HIP DEX KEYMAT process is based on the Hash-based Key Derivation 1481 Function (HKDF) defined in [RFC5869] and consists of two components, 1482 CKDF-Extract and CKDF-Expand. The CKDF-Extract function compresses a 1483 non-uniformly distributed key, such as the output of a Diffie-Hellman 1484 key derivation, to extract the key entropy into a fixed length 1485 output. The CKDF-Expand function takes either the output of the 1486 Extract function or directly uses a uniformly distributed key and 1487 expands the length of the key, repeatedly distributing the key 1488 entropy, to produce the keys needed. 1490 The key derivation for the Master Key SA employs always both the 1491 Extract and Expand phases. The Pair-wise Key SA needs only the 1492 Extract phase when the key is smaller or equal to 128 bits, but 1493 otherwise requires also the Expand phase. 1495 The CKDF-Extract function is the following operation: 1497 CKDF-Extract(I, IKM, info) -> PRK 1499 Inputs: 1500 I Random #I, provided by the Responder, from the PUZZLE 1501 parameter 1502 IKM Input keying material 1503 the Diffie-Hellman derived key, concatenated with the 1504 random I_NONCE value for the Master Key SA 1505 the Diffie-Hellman derived key, concatenated with the 1506 random values of the ENCRYPTED_KEY parameters in 1507 the same order as the HITs with sort(HIT-I | HIT-R) 1508 for the Pair-wise Key SA 1510 info sort(HIT-I | HIT-R) | "CKDF-Extract" 1511 Where the input text: "CKDF-Extract" 1512 Is the hex string: 0x434b44462d45787472616374 1514 Output: 1515 PRK a pseudorandom key (of RHASH_len/8 octets) 1517 The pseudorandom key PRK is calculated as follows: 1519 PRK = CMAC(I, IKM | info) 1521 The CKDF-Expand function is the following operation: 1523 CKDF-Expand(PRK, info, L) -> OKM 1525 Inputs: 1526 PRK a pseudorandom key of at least RHASH_len/8 octets 1527 (either the output from the extract step or the 1528 concatenation of the random values of the 1529 ENCRYPTED_KEY parameters in the same order as the 1530 HITs with sort(HIT-I | HIT-R) in case of no extract) 1531 info sort(HIT-I | HIT-R) | "CKDF-Expand" 1532 Where the input text: "CKDF-Expand" 1533 Is the hex string: 0x434b44462d457870616e64 1534 L length of output keying material in octets 1535 (<= 255*RHASH_len/8) 1537 Output: 1538 OKM output keying material (of L octets) 1540 The output keying material OKM is calculated as follows: 1542 N = ceil(L/(RHASH_len/8)) 1543 T = T(1) | T(2) | T(3) | ... | T(N) 1544 OKM = first L octets of T 1546 where 1548 T(0) = empty string (zero length) 1549 T(1) = CMAC(PRK, T(0) | info | 0x01) 1550 T(2) = CMAC(PRK, T(1) | info | 0x02) 1551 T(3) = CMAC(PRK, T(2) | info | 0x03) 1552 ... 1554 (where the constant concatenated to the end of each T(n) is a 1555 single octet.) 1557 sort(HIT-I | HIT-R) is defined as the network byte order 1558 concatenation of the two HITs, with the smaller HIT preceding the 1559 larger HIT, resulting from the numeric comparison of the two HITs 1560 interpreted as positive (unsigned) 128-bit integers in network byte 1561 order. 1563 The initial keys for the Master Key SA are drawn sequentially in the 1564 order that is determined by the numeric comparison of the two HITs, 1565 with the comparison method described in the previous paragraph. 1566 HOST_g denotes the host with the greater HIT value, and HOST_l the 1567 host with the lower HIT value. 1569 The drawing order for initial keys: 1571 1. HIP-gl encryption key for HOST_g's outgoing HIP packets 1573 2. HIP-gl integrity (CMAC) key for HOST_g's outgoing HIP packets 1575 3. HIP-lg encryption key for HOST_l's outgoing HIP packets 1577 4. HIP-lg integrity (CMAC) key for HOST_l's outgoing HIP packets 1579 The number of bits drawn for a given algorithm is the "natural" size 1580 of the keys regarding the algorithm defined in the HIP_CIPHER. For 1581 the mandatory algorithms, the following size applies: 1583 AES 128 bits 1585 If other key sizes are used, they must be treated as different 1586 encryption algorithms and defined separately. 1588 6.4. Initiation of a HIP Diet EXchange 1590 The initiation of a HIP DEX handshake proceeds as described in 1591 Section 6.6 of [RFC7401]. The I1 packet contents are specified in 1592 Section 5.3.1. 1594 6.5. Processing Incoming I1 Packets 1596 I1 packets in HIP DEX are handled almost identical to HIPv2 (see 1597 Section 6.7 of [RFC7401]). The main differences are that the 1598 Responder SHOULD select a HIP DEX HIT Suite in the R1 response. 1599 Moreover, as R1 packets are neither covered by a signature nor incur 1600 the overhead of generating an ephemeral Diffie-Hellman key-pair, pre- 1601 computation of an R1 is only marginally beneficial, but would incur 1602 additional memory resources at the Responder. Hence, the R1 pre- 1603 computation SHOULD be omitted in HIP DEX. 1605 Correspondingly, the modified conceptual processing rules for 1606 responding to an I1 packet are as follows: 1608 1. The Responder MUST check that the Responder's HIT in the received 1609 I1 packet is either one of its own HITs or NULL. Otherwise, it 1610 MUST drop the packet. 1612 2. If the Responder is in ESTABLISHED state, the Responder MAY 1613 respond to this with an R1 packet, prepare to drop an existing 1614 HIP security association with the peer, and stay at ESTABLISHED 1615 state. 1617 3. If the Responder is in I1-SENT state, it MUST make a comparison 1618 between the sender's HIT and its own (i.e., the receiver's) HIT. 1620 If the sender's HIT is greater than its own HIT, it should drop 1621 the I1 packet and stay at I1-SENT. If the sender's HIT is 1622 smaller than its own HIT, it SHOULD send the R1 packet and stay 1623 at I1-SENT. The HIT comparison is performed as defined in 1624 Section 6.3. 1626 4. If the implementation chooses to respond to the I1 packet with an 1627 R1 packet, it creates a new R1 according to the format described 1628 in Section 5.3.2. It chooses the HI based on the destination HIT 1629 and the DH_GROUP_LIST in the I1 packet. If the implementation 1630 does not support the DH group required by the Initiator or if the 1631 destination HIT in the I1 packet does not match the required DH 1632 group, it selects the mutually preferred and supported DH group 1633 based on the DH_GROUP_LIST parameter in the I1 packet. The 1634 implementation includes the corresponding ECDH public key in the 1635 HOST_ID parameter. If no suitable DH Group ID was contained in 1636 the DH_GROUP_LIST in the I1 packet, it sends an R1 packet with 1637 any suitable ECDH public key. 1639 5. If the received Responder's HIT in the I1 packet is not NULL, the 1640 Responder's HIT in the R1 packet MUST match the destination HIT 1641 in the I1 packet. Otherwise, the Responder MUST select a HIT 1642 with the same HIT Suite as the Initiator's HIT. If this HIT 1643 Suite is not supported by the Responder, it SHOULD select a 1644 REQUIRED HIT Suite from Section 5.2.10 of [RFC7401], which is 1645 currently RSA/DSA/SHA-256. Other than that, selecting the HIT is 1646 a local policy matter. 1648 6. The Responder expresses its supported HIP transport formats in 1649 the TRANSPORT_FORMAT_LIST as described in Section 5.2.11 of 1650 [RFC7401]. The Responder MUST provide at least one payload 1651 transport format type. 1653 7. The Responder sends the R1 packet to the source IP address of the 1654 I1 packet. 1656 Note that only steps 4 and 5 have been changed with regard to the 1657 processing rules of HIPv2. The considerations about R1 management 1658 (except pre-computation) and malformed I1 packets in Sections 6.7.1 1659 and 6.7.2 of [RFC7401] likewise apply to HIP DEX. 1661 6.6. Processing Incoming R1 Packets 1663 R1 packets in HIP DEX are handled identically to HIPv2 (see 1664 Section 6.8 in [RFC7401]) with the following exceptions: HIP DEX uses 1665 ECDH public keys as HIs and does not employ signatures. 1667 As R1 is not signed and no proof is possible in the authenticity of 1668 its contents, all processing of the R1 is provisional until verified 1669 by the R2 processing. 1671 The modified conceptual processing rules for responding to an R1 1672 packet are as follows: 1674 1. A system receiving an R1 MUST first check to see if it has sent 1675 an I1 packet to the originator of the R1 packet (i.e., it has a 1676 HIP association that is in state I1-SENT and that is associated 1677 with the HITs in the R1). Unless the I1 packet was sent in 1678 opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP 1679 addresses in the received R1 packet SHOULD be ignored by the R1 1680 processing and, when looking up the correct HIP association, the 1681 received R1 packet SHOULD be matched against the associations 1682 using only the HITs. If a match exists, the system processes 1683 the R1 packet as described below. 1685 2. Otherwise, if the system is in any state other than I1-SENT or 1686 I2-SENT with respect to the HITs included in the R1 packet, it 1687 SHOULD silently drop the R1 packet and remain in the current 1688 state. 1690 3. If the HIP association state is I1-SENT or I2-SENT, the received 1691 Initiator's HIT MUST correspond to the HIT used in the original 1692 I1 packet. Also, the Responder's HIT MUST correspond to the one 1693 used in the I1 packet, unless this packet contained a NULL HIT. 1695 4. If the HIP association state is I1-SENT, and multiple valid R1 1696 packets are present, the system MUST select from among the R1 1697 packets with the largest R1 generation counter. 1699 5. The system MUST check that the Initiator's HIT Suite is 1700 contained in the HIT_SUITE_LIST parameter in the R1 packet 1701 (i.e., the Initiator's HIT Suite is supported by the Responder). 1702 If the HIT Suite is supported by the Responder, the system 1703 proceeds normally. Otherwise, the system MAY stay in state 1704 I1-SENT and restart the HIP DEX handshake by sending a new I1 1705 packet with an Initiator HIT that is supported by the Responder 1706 and hence is contained in the HIT_SUITE_LIST in the R1 packet. 1707 The system MAY abort the handshake if no suitable source HIT is 1708 available. The system SHOULD wait for an acceptable time span 1709 to allow further R1 packets with higher R1 generation counters 1710 or different HIT and HIT Suites to arrive before restarting or 1711 aborting the HIP DEX handshake. 1713 6. The system MUST check that the DH Group ID in the HOST_ID 1714 parameter in the R1 matches the first DH Group ID in the 1715 Responder's DH_GROUP_LIST in the R1 packet, and also that this 1716 Group ID corresponds to a value that was included in the 1717 Initiator's DH_GROUP_LIST in the I1 packet. If the DH Group ID 1718 of the HOST_ID parameter does not express the Responder's best 1719 choice, the Initiator can conclude that the DH_GROUP_LIST in the 1720 I1 or R1 packet was adversely modified. In such a case, the 1721 Initiator MAY send a new I1 packet; however, it SHOULD NOT 1722 change its preference in the DH_GROUP_LIST in the new I1 packet. 1723 Alternatively, the Initiator MAY abort the HIP DEX handshake. 1724 Moreover, if the DH Group ID indicated in the HOST_ID parameter 1725 does not match the DH Group ID of the HI employed by the 1726 Initiator, the system SHOULD wait for an acceptable time span to 1727 allow further R1 packets with different DH Group IDs to arrive 1728 before restarting or aborting the HIP DEX handshake. When 1729 restarting the handshake, the Initiator MUST consult local 1730 policies (see Section 7) regarding the use of another, mutually 1731 supported DH group for the subsequent handshake with the 1732 Responder. 1734 7. If the HIP association state is I2-SENT, the system MAY re-enter 1735 state I1-SENT and process the received R1 packet if it has a 1736 larger R1 generation counter than the R1 packet responded to 1737 previously. 1739 8. The system SHOULD attempt to validate the HIT against the 1740 received Host Identity by using the received Host Identity to 1741 construct a HIT and verify that it matches the Sender's HIT. 1743 9. The system MUST store the received R1 generation counter for 1744 future reference. 1746 10. The system attempts to solve the puzzle in the R1 packet. The 1747 system MUST terminate the search after exceeding the remaining 1748 lifetime of the puzzle. If the puzzle is not successfully 1749 solved, the implementation MAY either resend the I1 packet 1750 within the retry bounds or abandon the HIP base exchange. 1752 11. The system computes standard Diffie-Hellman keying material 1753 according to the public value and Group ID provided in the 1754 HOST_ID parameter. The Diffie-Hellman keying material Kij is 1755 used for key extraction as specified in Section 6.3. 1757 12. The system selects the HIP_CIPHER ID from the choices presented 1758 in the R1 packet and uses the selected values subsequently when 1759 generating and using encryption keys, and when sending the I2 1760 packet. If the proposed alternatives are not acceptable to the 1761 system, it MAY either resend an I1 packet within the retry 1762 bounds or abandon the HIP base exchange. 1764 13. The system chooses one suitable transport format from the 1765 TRANSPORT_FORMAT_LIST and includes the respective transport 1766 format parameter in the subsequent I2 packet. 1768 14. The system initializes the remaining variables in the associated 1769 state, including Update ID counters. 1771 15. The system prepares and sends an I2 packet as described in 1772 Section 5.3.3. 1774 16. The system SHOULD start a timer whose timeout value SHOULD be 1775 larger than the worst-case anticipated RTT, and MUST increment a 1776 trial counter associated with the I2 packet. The sender SHOULD 1777 retransmit the I2 packet upon a timeout and restart the timer, 1778 up to a maximum of I2_RETRIES_MAX tries. 1780 17. If the system is in state I1-SENT, it SHALL transition to state 1781 I2-SENT. If the system is in any other state, it remains in the 1782 current state. 1784 Note that step 4 from the original processing rules of HIPv2 1785 (signature verification) has been removed in the above processing 1786 rules for HIP DEX. Moreover, step 7 of the original processing rules 1787 has been adapted in step 6 above to account for the fact that HIP DEX 1788 uses ECDH public keys as HIs. The considerations about malformed R1 1789 packets in Sections 6.8.1 of [RFC7401] also apply to HIP DEX. 1791 6.7. Processing Incoming I2 Packets 1793 The processing of I2 packets follows similar rules as HIPv2 (see 1794 Section 6.9 of [RFC7401]). The main differences to HIPv2 are that 1795 HIP DEX introduces a new session key exchange via the ENCRYPTED_KEY 1796 parameter as well as an I2 reception acknowledgement for 1797 retransmission purposes. Moreover, with HIP DEX the Initiator is 1798 responsible for triggering retransmissions, whereas the Responder 1799 merely replies to received I2 packets. 1801 The modified HIP DEX conceptual processing rules for responding to an 1802 I2 packet are: 1804 1. The system MAY perform checks to verify that the I2 packet 1805 corresponds to a recently sent R1 packet. Such checks are 1806 implementation dependent. See Appendix A in [RFC7401] for a 1807 description of an example implementation. 1809 2. The system MUST check that the Responder's HIT corresponds to 1810 one of its own HITs and MUST drop the packet otherwise. 1812 3. The system MUST further check that the Initiator's HIT Suite is 1813 supported. The Responder SHOULD silently drop I2 packets with 1814 unsupported Initiator HITs. 1816 4. The system MUST validate the Initiator's HI per Section 9.1. 1818 5. If the system's state machine is in the R2-SENT state, the 1819 system MUST check to see if the newly received I2 packet is 1820 similar to the one that triggered moving to R2-SENT. If so, it 1821 MUST retransmit a previously sent R2 packet and reset the 1822 R2-SENT timer. The system SHOULD re-use the previously 1823 established state to re-create the corresponding R2 packet in 1824 order to prevent unnecessary computation overhead. 1826 6. If the system's state machine is in the I2-SENT state, the 1827 system MUST make a comparison between its local and sender's 1828 HITs (similarly as in Section 6.3). If the local HIT is smaller 1829 than the sender's HIT, it should drop the I2 packet, use the 1830 peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce 1831 #I from the R1 packet received earlier, and get the local 1832 Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J 1833 from the I2 packet sent to the peer earlier. Otherwise, the 1834 system processes the received I2 packet and drops any previously 1835 derived Diffie-Hellman keying material Kij and ENCRYPTED_KEY 1836 keying material it might have generated upon sending the I2 1837 packet previously. The peer Diffie-Hellman key, ENCRYPTED_KEY, 1838 and the nonce #J are taken from the just arrived I2 packet. The 1839 local Diffie-Hellman key, ENCRYPTED_KEY keying material, and the 1840 nonce #I are the ones that were sent earlier in the R1 packet. 1842 7. If the system's state machine is in the I1-SENT state, and the 1843 HITs in the I2 packet match those used in the previously sent I1 1844 packet, the system uses this received I2 packet as the basis for 1845 the HIP association it was trying to form, and stops 1846 retransmitting I1 packets (provided that the I2 packet passes 1847 the additional checks below). 1849 8. If the system's state machine is in any state other than 1850 R2-SENT, the system SHOULD check that the echoed R1 generation 1851 counter in the I2 packet is within the acceptable range if the 1852 counter is included. Implementations MUST accept puzzles from 1853 the current generation and MAY accept puzzles from earlier 1854 generations. If the generation counter in the newly received I2 1855 packet is outside the accepted range, the I2 packet is stale 1856 (and perhaps replayed) and SHOULD be dropped. 1858 9. The system MUST validate the solution to the puzzle as described 1859 in Section 6.1. 1861 10. The I2 packet MUST have a single value in the HIP_CIPHER 1862 parameter, which MUST match one of the values offered to the 1863 Initiator in the R1 packet. 1865 11. The system MUST derive Diffie-Hellman keying material Kij based 1866 on the public value and Group ID in the HOST_ID parameter. This 1867 keying material is used to derive the keys of the Master Key SA 1868 as described in Section 6.3. If the Diffie-Hellman Group ID is 1869 unsupported, the I2 packet is silently dropped. If the 1870 processing time for the derivation of the Diffie-Hellman keying 1871 material Kij is likely to cause premature I2 retransmissions by 1872 the Initiator, the system MAY send a NOTIFY packet before 1873 starting the key derivation process. The NOTIFY packet contains 1874 a NOTIFICATION parameter with Notify Message Type 1875 I2_ACKNOWLEDGEMENT. The NOTIFICATION parameter indicates the 1876 anticipated remaining processing time for the I2 packet in 1877 milliseconds as two-octet Notification Data. 1879 12. The implementation SHOULD also verify that the Initiator's HIT 1880 in the I2 packet corresponds to the Host Identity sent in the I2 1881 packet. (Note: some middleboxes may not be able to make this 1882 verification.) 1884 13. The system MUST process the TRANSPORT_FORMAT_LIST parameter. 1885 Other documents specifying transport formats (e.g., [RFC7402]) 1886 contain specifications for handling any specific transport 1887 selected. 1889 14. The system MUST verify the HIP_MAC according to the procedures 1890 in Section 6.2. 1892 15. If the checks above are valid, then the system proceeds with 1893 further I2 processing; otherwise, it discards the I2 and its 1894 state machine remains in the same state. 1896 16. The system MUST decrypt the keying material from the 1897 ENCRYPTED_KEY parameter. This keying material is a partial 1898 input to the key derivation process for the Pair-wise Key SA 1899 (see Section 6.3). 1901 17. The system initializes the remaining variables in the associated 1902 state, including Update ID counters. 1904 18. Upon successful processing of an I2 packet when the system's 1905 state machine is in state UNASSOCIATED, I1-SENT, I2-SENT, or 1906 R2-SENT, an R2 packet is sent as described in Section 5.3.4 and 1907 the system's state machine transitions to state R2-SENT. 1909 19. Upon successful processing of an I2 packet when the system's 1910 state machine is in state ESTABLISHED, the old HIP association 1911 is dropped and a new one is installed, an R2 packet is sent as 1912 described in Section 5.3.4, and the system's state machine 1913 transitions to R2-SENT. 1915 20. Upon the system's state machine transitioning to R2-SENT, the 1916 system starts a timer. The state machine transitions to 1917 ESTABLISHED if some data has been received on the incoming HIP 1918 association, or an UPDATE packet has been received (or some 1919 other packet that indicates that the peer system's state machine 1920 has moved to ESTABLISHED). If the timer expires (allowing for a 1921 maximal amount of retransmissions of I2 packets), the state 1922 machine transitions to ESTABLISHED. 1924 Note that steps 11 (encrypted HOST_ID) and 15 (signature 1925 verification) from the original processing rules of HIPv2 have been 1926 removed in the above processing rules for HIP DEX. Moreover, step 10 1927 of the HIPv2 processing rules has been adapted to account for 1928 optional extension of the retransmission mechanism. Step 16 has been 1929 added to the processing rules in this document. The considerations 1930 about malformed I2 packets in Sections 6.9.1 of [RFC7401] also apply 1931 to HIP DEX. 1933 6.8. Processing Incoming R2 Packets 1935 R2 packets in HIP DEX are handled identically to HIPv2 (see 1936 Section 6.10 of [RFC7401]) with the following exceptions: HIP DEX 1937 introduces a new session key exchange via the ENCRYPTED_KEY parameter 1938 and does not employ signatures. 1940 The modified conceptual processing rules for responding to an R2 1941 packet are as follows: 1943 1. If the system is in any other state than I2-SENT, the R2 packet 1944 is silently dropped. 1946 2. The system MUST verify that the HITs in use correspond to the 1947 HITs that were received in the R1 packet that caused the 1948 transition to the I2-SENT state. 1950 3. The system MUST verify the HIP_MAC according to the procedures in 1951 Section 6.2. 1953 4. The system MUST re-evaluate the DH_GROUP_LIST, HIP_CIPHER, 1954 HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST parameters in the R2 1955 packet and compare the results against the chosen suites. 1957 5. The system MUST validate the Responder's HI per Section 9.1. 1959 6. If any of the checks above fail, there is a high probability of 1960 an ongoing man-in-the-middle or other security attack. The 1961 system SHOULD act accordingly, based on its local policy. 1963 7. The system MUST decrypt the keying material from the 1964 ENCRYPTED_KEY parameter. This keying material is a partial input 1965 to the key derivation process for the Pair-wise Key SA (see 1966 Section 6.3). 1968 8. Upon successful processing of the R2 packet, the state machine 1969 transitions to state ESTABLISHED. 1971 Note that step 4 (signature verification) from the original 1972 processing rules of HIPv2 has been replaced with a negotiation re- 1973 evaluation in the above processing rules for HIP DEX. Moreover, step 1974 6 has been added to the processing rules. 1976 6.9. Processing Incoming NOTIFY Packets 1978 Processing of NOTIFY packets is OPTIONAL. If processed, any errors 1979 in a received NOTIFICATION parameter SHOULD be logged. Received 1980 errors MUST be considered only as informational, and the receiver 1981 SHOULD NOT change its HIP state purely based on the received NOTIFY 1982 packet. 1984 If a NOTIFY packet is received in state I2-SENT, this packet is an I2 1985 reception acknowledgement of the optional retransmission mechanism 1986 extension and SHOULD be processed. The following steps define the 1987 conceptual processing rules for such incoming NOTIFY packets in state 1988 I2-SENT: 1990 1. The system MUST verify that the HITs in use correspond to the 1991 HITs that were received in the R1 packet that caused the 1992 transition to the I2-SENT state. If this check fails, the NOTIFY 1993 packet MUST be dropped silently. 1995 2. If the NOTIFY packet contains a NOTIFICATION parameter with 1996 Notify Message Type I2_ACKNOWLEDGEMENT, the system SHOULD set the 1997 I2 retransmission timer to the I2 processing time indicated in 1998 the NOTIFICATION parameter plus half the RTT-based timeout value. 1999 The system MUST NOT set the retransmission timeout to a higher 2000 value than allowed by a local policy. Moreover, the system 2001 SHOULD reset the I2 retransmission timer to the RTT-based timeout 2002 value after the next I2 retransmission. 2004 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets 2006 UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX 2007 as in HIPv2 (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). 2008 The only difference is the that the HIP_SIGNATURE is never present 2009 and, therefore, is not required to be processed by the receiving 2010 party. 2012 [RFC7402] specifies the rekeying of an existing HIP SA using the 2013 UPDATE message. This rekeying procedure can also be used with HIP 2014 DEX. However, where rekeying involves a new Diffie-Hellman key 2015 exchange, HIP DEX peers MUST establish a new HIP association in order 2016 to create a new Pair-wise Key SA due to the use of static ECDH key- 2017 pairs with HIP DEX. 2019 6.11. Handling State Loss 2021 Implementors MAY choose to use non-volatile, secure storage for HIP 2022 states in order for them to survive a system reboot. If no secure 2023 storage capabilities are available, the system SHOULD delete the 2024 corresponding HIP state, including the keying material. If the 2025 implementation does drop the state (as RECOMMENDED), it MUST also 2026 drop the peer's R1 generation counter value, unless a local policy 2027 explicitly defines that the value of that particular host is stored. 2029 Storing of the R1 generation counter values and ENCRYPTED_KEY counter 2030 (Section 5.2.5) MUST be configured by explicit HITs. 2032 7. HIP Policies 2034 There are a number of variables that will influence the HIP exchanges 2035 that each host must support. The value of puzzle difficulty K used 2036 in the HIP R1 must be chosen with care. Values for the K that are 2037 too high will exclude clients with weak CPUs because these devices 2038 cannot solve the puzzle within a reasonable amount of time. The K 2039 value should only be raised if a Responder is under high load, i.e., 2040 it cannot process all incoming HIP handshakes any more. 2042 If a Responder is not under high load, K SHOULD be 0. 2044 All HIP DEX implementations SHOULD provide for an Access Control List 2045 (ACL), representing for which hosts they accept HIP diet exchanges, 2046 and the preferred transport format and local lifetimes. Wildcarding 2047 SHOULD be supported for such ACLs. 2049 7.1. HIT/HI ACL 2051 Both the Initiator and Responder SHOULD implement an ACL. Minimally, 2052 these ACLs will be a list of trusted HIT/HIs. They may also contain 2053 the password used in the password-based two-factor authentication 2054 (Appendix A) and preferred HIT Suite. 2056 ACL processing is applied to all HIP packets. A HIP peer MAY reject 2057 any packet where the Receiver's HIT is not in the ACL. The HI (in 2058 the R1, I2, and optionally NOTIFY packets) MUST be validated as well, 2059 when present in the ACL. This is the defense against collision and 2060 second-image attacks on the HIT generation. 2062 Devices with no input mechanism (e.g. sensors) SHOULD accept R1 2063 packets from unknown HITs. These R1 packets SHOULD contain the start 2064 of the password-based two-factor authentication . If the R2 for this 2065 HIT indicates success, then the device may add this HIT/HI to its ACL 2066 for future use. 2068 Devices unable to manage an ACL (e.g. sensors) are subject to MITM 2069 attacks, even with the use of the password authentication (password 2070 theft by attacker). As long as the other peer (e.g. sensor 2071 controller) does use an ACL, the attack can be recognized there and 2072 addressed. This is often seen where the sensor does not appear as 2073 properly operating with the controller, as the attacker cannot 2074 impersonate information in the ACL. 2076 8. Interoperability between HIP DEX and HIPv2 2078 HIP DEX and HIPv2 both use the same protocol number and packet 2079 formats. Hence, an implementation that either supports HIP DEX or 2080 HIPv2 has to be able to detect the dialect that the peer is speaking. 2081 This section outlines how a HIP DEX implementation can achieve such 2082 detection for the two relevant cases where: 2084 1. the Initiator supports HIP DEX and the Responder supports HIP 2085 BEX, 2087 2. the Initiator supports HIP BEX and the Responder supports HIP 2088 DEX. 2090 In the first case, the HIP DEX implementation (Initiator) inspects 2091 the Responder's HIT prior to sending the I1 packet. If the OGA ID 2092 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 2093 DEX implementation cancels the handshake. If the Responder is 2094 unknown prior to sending the I1 packet (i.e., opportunistic mode), 2095 the HIP DEX implementation performs the above check on reception of 2096 the R1 packet and cancels the handshake in case of a negative result. 2098 In both failure scenarios, the implementation should report an error 2099 to the user via appropriate means. 2101 In the second case, the HIP DEX implementation (Responder) inspects 2102 the Initiator's HIT on reception of an I1 packet. If the OGA ID 2103 field of this HIT does not indicate the HIP DEX HIT Suite ID, the HIP 2104 DEX implementation cancels the handshake and sends an ICMP packet 2105 with type Parameter Problem, with the Pointer pointing to the source 2106 HIT, to the Initiator. As an off-path adversary could also send such 2107 an ICMP packet with the aim to prevent the HIP DEX handshake from 2108 completing, the Initiator SHOULD NOT react to an ICMP message before 2109 retransmission counter reaches I1_RETRIES_MAX in its state machine 2110 (see Table 3 in [RFC7401]). 2112 9. Security Considerations 2114 HIP DEX closely resembles HIPv2. As such, the security 2115 considerations discussed in Section 8 of [RFC7401] similarly apply to 2116 HIP DEX. HIP DEX, however, replaces the SIGMA-based authenticated 2117 Diffie-Hellman key exchange of HIPv2 with an exchange of random 2118 keying material that is encrypted with a Diffie-Hellman derived key. 2119 Both the Initiator and Responder contribute to this keying material. 2120 As a result, the following additional security considerations apply 2121 to HIP DEX: 2123 o The strength of the keys for both the Master and Pair-wise Key SAs 2124 is based on the quality of the random keying material generated by 2125 the Initiator and the Responder. As either peer may be a sensor 2126 or an actuator device, there is a natural concern about the 2127 quality of its random number generator. Thus at least a CSPRNG 2128 SHOULD be used. 2130 o HIP DEX lacks the Forward Secrecy (FS) property of HIPv2. 2131 Consequently, if an HI is compromised, all previous HIP 2132 connections protected with that HI are compromised as explained in 2133 Section 1. 2135 o The HIP DEX HIT generation may present new attack opportunities. 2136 Hence, HIP DEX HITs MUST NOT be used as the only means to identify 2137 a peer in an ACL. Instead, the use of the peer's HI is 2138 recommended as explained in Section 3. 2140 o The R1 packet is unauthenticated and offers an adversary a new 2141 attack vector against the Initiator. This is mitigated by only 2142 processing a received R1 packet when the Initiator has previously 2143 sent a corresponding I1 packet. Moreover, the Responder repeats 2144 the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, and 2145 TRANSPORT_FORMAT_LIST parameters in the R2 packet in order to 2146 enable the Initiator to verify that these parameters have not been 2147 modified by an attacker in the unprotected R1 packet as explained 2148 in Section 6.8. 2150 o Contrary to HIPv2, HIP DEX does not provide for end-point 2151 anonymity for the Initiator or Responder. Thus, any signaling 2152 that indicates such anonymity should be ignored as explained in 2153 Section 1.1. 2155 o It is critical to properly manage the ENCRYPTED_KEY counter 2156 (Section 5.2.5). If non-volatile store is used to maintain HIP 2157 state across system resets, then this counter MUST be part of the 2158 state store. 2160 The optional retransmission extension of HIP DEX is based on a NOTIFY 2161 packet that the Responder can use to inform the Initiator about the 2162 reception of an I2 packet. The Responder, however, cannot protect 2163 the authenticity of this packet as it did not yet set up the Master 2164 Key SA. Hence, an eavesdropping adversary may send spoofed reception 2165 acknowledgements for an overheard I2 packet and signal an arbitrary 2166 I2 processing time to the Initiator. The adversary can, e.g., 2167 indicate a lower I2 processing time than actually required by the 2168 Responder in order to cause premature retransmissions. To protect 2169 against this attack, the Initiator SHOULD set the NOTIFY-based 2170 timeout value to the maximum indicated packet processing time in case 2171 of conflicting NOTIFY packets. This allows the legitimate Responder 2172 to extend the retransmission timeout to the intended length. The 2173 adversary, however, can still arbitrarily delay the protocol 2174 handshake beyond the Responder's actual I2 processing time. To limit 2175 the extend of such a maliciously induced handshake delay, this 2176 specification additionally requires the Initiator not to set the 2177 NOTIFY-based timeout value higher than allowed by a local policy. 2179 Section 5.3.1 mentions that implementations need to be able to handle 2180 storms of I1 packets. Contrary to HIPv2, R1 packets cannot be pre- 2181 computed in HIP DEX and also the state machine does not include an 2182 "R1_SENT" state (that would enable caching of R1 packets). 2183 Therefore, an implementation has to cache information (e.g., at least 2184 the HITs) from incoming I1 packets and rate control the incoming I1 2185 packets to avoid unnecessary packet processing during I1 packet 2186 storms. 2188 9.1. Need to Validate Public Keys 2190 With the curves specified here, there is a straightforward key 2191 extraction attack, which is a very serious problem with the use of 2192 static keys by HIP-DEX. Thus it is MANDATORY to validate the peer's 2193 Public Key. 2195 With the NIST curves, there are no internal length markers, so each 2196 number representation occupies as many octets as implied by the curve 2197 parameters. For P-256, this means that each of X and Y use 32 2198 octets, padded on the left by zeros if necessary. For P-384, they 2199 take 48 octets each. 2201 For Curve25519 and Curve448, the contents of the public value are the 2202 byte string inputs and outputs of the corresponding functions defined 2203 in [RFC7748]: 32 bytes for EC25519 and 56 bytes for EC448. 2205 The validation is done in Section 6.7, step 4 and Section 6.8, step 2206 5. 2208 10. IANA Considerations 2210 The following changes to the "Host Identity Protocol (HIP) 2211 Parameters" registries have been made: 2213 ENCRYPTED_KEY "ENCRYPTED_KEY" with type number TBD1 (suggested: 643) 2214 (see Section 5.2.5) in the "Parameter Types" subregistry of the 2215 "Host Identity Protocol (HIP) Parameters" registry. 2217 DH_GROUP_LIST This document defines the new DH_GROUPS Curve25519 2218 with value TBD7 (suggested: 12) and Curve448 with value TBD8 2219 (suggested: 13) (see Section 5.2.1) in the "Group IDs" subregistry 2220 of the "Host Identity Protocol (HIP) Parameters" registry. 2222 HIT Suite ID This document defines the new HIT Suite "ECDH/FOLD" 2223 without four-bit ID of TBD2 (suggested: 4) and eight-bit encoding 2224 of TBD3 (suggested: 0x40) (see Section 5.2.4) in the "HIT Suite 2225 ID" subregistry of the "Host Identity Protocol (HIP) Parameters" 2226 registry. 2228 HIP Cipher ID This document defines the new HIP Cipher ID "AES- 2229 128-CTR" with type number TBD4 (suggested: 5) (see Section 5.2.2) 2230 in the "HIP Cipher ID" subregistry of the "Host Identity Protocol 2231 (HIP) Parameters" registry. 2233 HI Algorithm This document defines the new HI Algorithm "ECDH" with 2234 type number TBD5 (suggested: 11) (see Section 5.2.3) in the "HI 2235 Algorithm" subregistry of the "Host Identity Protocol (HIP) 2236 Parameters" registry. 2238 I_NONCE "I_NONCE" with type number TBD6 (suggested: 644) (see 2239 Section 5.2.6) in the "Parameter Types" subregistry of the "Host 2240 Identity Protocol (HIP) Parameters" registry. 2242 ECC Curve Label This document specifies a new algorithm-specific 2243 subregistry named "ECDH Curve Label". The values for this 2244 subregistry are defined in Section 5.2.1. The complete list of 2245 algorithms for the DH_GROUP_LIST parameter are listed in the 2246 "Group IDs" subregistry of the "Host Identity Protocol (HIP) 2247 Parameters" registry. 2249 11. Acknowledgements 2251 The drive to put HIP on a cryptographic 'Diet' came out of a number 2252 of discussions with sensor vendors at IEEE 802.15 meetings. David 2253 McGrew was very helpful in crafting this document. Special thanks to 2254 Mohit Sethi in helping with the draft during IESG process. 2256 12. Changelog 2258 This section summarizes the changes made from draft-moskowitz-hip-rg- 2259 dex-05, which was the first stable version of the draft. Note that 2260 the draft was renamed after draft-moskowitz-hip-rg-dex-06. 2262 The draft was then renamed from draft-moskowitz-hip-dex to draft- 2263 ietf-hip-dex. 2265 12.1. Changes in draft-ietf-hip-dex-20 2267 o Clarified text on AES-CTR for HIP parameter encryption. 2269 o Clarified text on R2 processing to validate content of R1. 2271 o Clarified Applicability section. 2273 o Expanded Fig 1. 2275 o Clarified differences between BEX and DEX state machines. 2277 o ESP transform is MTI and ESP-TCP is Experimental. 2279 12.2. Changes in draft-ietf-hip-dex-19 2281 o Replaced reference to RFC4493 for CMAC with NIST SP800-38B. 2283 o Remove NIST P-521 from DH_GROUP_LIST. 2285 o Remove NULL-ENCRYPT. 2287 o Added reference to rfc8005 for HIT lookup in DNS. 2289 o Remove setting Control bit: A. 2291 o Many textual improvements per Benjamin Kaduk comments. 2293 12.3. Changes in draft-ietf-hip-dex-18 2295 o Changed Perfect Forward Secrecy to Forward Secrecy. 2297 12.4. Changes in draft-ietf-hip-dex-17 2299 o Added hex values for strings CKDF-Extract and CKDF-Expand. 2301 o Replace Perfect Forward Secrecy with Forward Secrecy. 2303 12.5. Changes in draft-ietf-hip-dex-16 2305 o Remove old placeholder text. 2307 o Remove SECP160R1. Experience has shown EC25519 performance equal 2308 enough to not need it. 2310 12.6. Changes in draft-ietf-hip-dex-15 2312 o Added Public Key validation in I2 and R2 processing. 2314 o Added ACL processing (Section 7.1). 2316 o Added IANA instructions for DH_GROUP_LIST. 2318 12.7. Changes in draft-ietf-hip-dex-14 2320 o Changes to (Section 5.4) per Jeff Ahrenholz for Suresh Krishnan 2321 comment 2323 12.8. Changes in draft-ietf-hip-dex-12 and 13 2325 o Nits from Jeff Ahrenholz (including some formatting issues) 2327 12.9. Changes in draft-ietf-hip-dex-11 and 12 2329 o Included more precise references to the IANA subregistries 2331 o Addressed GEN-ART feedback from Francis Dupont 2333 o Added reasoning for FS in a separate section, and it is mentioned 2334 also in the abstract and intro. 2336 o Donald Eastlake's (secdir) nits addressed 2338 o Resolved IANA nits from Amanda Baber. 2340 o New sections: "Why introduce folding" (Section 3.2.1), "SECP160R1 2341 Considered Unsafe" (removed in ver 16), "Need to Validate Public 2342 Keys" (Section 9.1), and "I_NONCE" (Section 5.2.6) to address Eric 2343 Rescorla's concerns. 2345 12.10. Changes in draft-ietf-hip-dex-11 2347 o Update IANA considerations as requested by Eric Envyncke 2349 12.11. Changes in draft-ietf-hip-dex-10 2351 o Explanations on why the document includes so many SHOULDs 2353 12.12. Changes in draft-ietf-hip-dex-09 2355 o Fixed values for 2357 * DH_GROUP_LIST 2359 * HIT_SUITE_LIST 2361 to match [RFC7401]. 2363 12.13. Changes in draft-ietf-hip-dex-05 2365 o Clarified main differences between HIP BEX and HIP DEX in 2366 Section 1. 2368 o Addressed MitM attack in Section 8. 2370 o Minor editorial changes. 2372 12.14. Changes in draft-ietf-hip-dex-04 2374 o Added new paragraph on rekeying procedure with HIP DEX. 2376 o Updated references. 2378 o Editorial changes. 2380 12.15. Changes in draft-ietf-hip-dex-03 2382 o Added new section on HIP DEX/HIPv2 interoperability 2384 o Added reference to RFC4493 for CMAC. 2386 o Added reference to RFC5869 for CKDF. 2388 o Added processing of NOTIFY message in I2-SENT of state diagram. 2390 o Editorial changes. 2392 12.16. Changes in draft-ietf-hip-dex-02 2394 o Author address change. 2396 12.17. Changes in draft-ietf-hip-dex-01 2398 o Added the new ECDH groups of Curve25519 and Curve448 from RFC 2399 7748. 2401 12.18. Changes in draft-ietf-hip-dex-00 2403 o The Internet Draft was adopted by the HIP WG. 2405 12.19. Changes in draft-moskowitz-hip-rg-dex-06 2407 o A major change in the ENCRYPT parameter to use AES-CTR rather than 2408 AES-CBC. 2410 12.20. Changes in draft-moskowitz-hip-dex-00 2412 o Draft name change. HIPRG ended in IRTF, HIP DEX is now individual 2413 submission. 2415 o Added the change section. 2417 o Added a Definitions section. 2419 o Changed I2 and R2 packets to reflect use of AES-CTR for 2420 ENCRYPTED_KEY parameter. 2422 o Cleaned up KEYMAT Generation text. 2424 o Added Appendix with C code for the ECDH shared secret generation 2425 on an 8 bit processor. 2427 12.21. Changes in draft-moskowitz-hip-dex-01 2429 o Numerous editorial changes. 2431 o New retransmission strategy. 2433 o New HIT generation mechanism. 2435 o Modified layout of ENCRYPTED_KEY parameter. 2437 o Clarify use puzzle difficulty of zero under normal network 2438 conditions. 2440 o Align inclusion directive of R1_COUNTER with HIPv2 (from SHOULD to 2441 MUST). 2443 o Align inclusion of TRANSPORT_FORMAT_LIST with HIPv2 (added to R1 2444 and I2). 2446 o HIP_CIPHER, HIT_SUITE_LIST, and TRANSPORT_FORMAT_LIST must now be 2447 echoed in R2 packet. 2449 o Added new author. 2451 12.22. Changes in draft-moskowitz-hip-dex-02 2453 o Introduced formal definition of FOLD function. 2455 o Clarified use of CMAC for puzzle computation in section "Solving 2456 the Puzzle". 2458 o Several editorial changes. 2460 12.23. Changes in draft-moskowitz-hip-dex-03 2462 o Addressed HI crypto agility. 2464 o Clarified purpose of secret exchanged via ENCRYPTED_KEY parameter. 2466 o Extended the IV in the ENCRYPTED_KEY parameter. 2468 o Introduced forward-references to HIP DEX KEYMAT process and 2469 improved KEYMAT section. 2471 o Replaced Appendix A on "C code for ECC point multiplication" with 2472 short discussion in introduction. 2474 o Updated references. 2476 o Further editorial changes. 2478 12.24. Changes in draft-moskowitz-hip-dex-04 2480 o Improved retransmission extension. 2482 o Updated and strongly revised packet processing rules. 2484 o Updated security considerations. 2486 o Updated IANA considerations. 2488 o Move the HI Algorithm for ECDH to a value of 11. 2490 o Many editorial changes. 2492 13. References 2494 13.1. Normative References 2496 [NIST.SP.800-38B] 2497 Dworkin, M., "Recommendation for block cipher modes of 2498 operation :", National Institute of Standards and 2499 Technology report, DOI 10.6028/nist.sp.800-38b, 2016. 2501 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2502 Requirement Levels", BCP 14, RFC 2119, 2503 DOI 10.17487/RFC2119, March 1997, 2504 . 2506 [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) 2507 Counter Mode With IPsec Encapsulating Security Payload 2508 (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, 2509 . 2511 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 2512 Control Message Protocol (ICMPv6) for the Internet 2513 Protocol Version 6 (IPv6) Specification", STD 89, 2514 RFC 4443, DOI 10.17487/RFC4443, March 2006, 2515 . 2517 [RFC6261] Keranen, A., "Encrypted Signaling Transport Modes for the 2518 Host Identity Protocol", RFC 6261, DOI 10.17487/RFC6261, 2519 May 2011, . 2521 [RFC7343] Laganier, J. and F. Dupont, "An IPv6 Prefix for Overlay 2522 Routable Cryptographic Hash Identifiers Version 2 2523 (ORCHIDv2)", RFC 7343, DOI 10.17487/RFC7343, September 2524 2014, . 2526 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 2527 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 2528 RFC 7401, DOI 10.17487/RFC7401, April 2015, 2529 . 2531 [RFC7402] Jokela, P., Moskowitz, R., and J. Melen, "Using the 2532 Encapsulating Security Payload (ESP) Transport Format with 2533 the Host Identity Protocol (HIP)", RFC 7402, 2534 DOI 10.17487/RFC7402, April 2015, 2535 . 2537 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2538 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2539 May 2017, . 2541 13.2. Informative References 2543 [DH76] Diffie, W. and M. Hellman, "New Directions in 2544 Cryptography", IEEE Transactions on Information 2545 Theory vol. IT-22, number 6, pages 644-654, Nov 1976. 2547 [HWZ13] Hummen, R., Wirtz, H., Ziegeldorf, J., Hiller, J., and K. 2548 Wehrle, "Tailoring End-to-End IP Security Protocols to the 2549 Internet of Things", in Proceedings of IEEE International 2550 Conference on Network Protocols (ICNP 2013), October 2013. 2552 [I-D.ietf-hip-rfc4423-bis] 2553 Moskowitz, R. and M. Komu, "Host Identity Protocol 2554 Architecture", draft-ietf-hip-rfc4423-bis-20 (work in 2555 progress), February 2019. 2557 [IEEE.802-11.2007] 2558 Engineers, I. O. E. A. E., "Information technology - 2559 Telecommunications and information exchange between 2560 systems - Local and metropolitan area networks - Specific 2561 requirements - Part 11: Wireless LAN Medium Access Control 2562 (MAC) and Physical Layer (PHY) Specifications", 2563 IEEE Standard 802.11, June 2007, 2564 . 2567 [IEEE.802-15-4.2011] 2568 Engineers, I. O. E. A. E., "Information technology - 2569 Telecommunications and information exchange between 2570 systems - Local and metropolitan area networks - Specific 2571 requirements - Part 15.4: Wireless Medium Access Control 2572 (MAC) and Physical Layer (PHY) Specifications for Low-Rate 2573 Wireless Personal Area Networks (WPANs)", IEEE Standard 2574 802.15.4, September 2011, 2575 . 2578 [LN08] Liu, A. and H. Ning, "TinyECC: A Configurable Library for 2579 Elliptic Curve Cryptography in Wireless Sensor Networks", 2580 in Proceedings of International Conference on Information 2581 Processing in Sensor Networks (IPSN 2008), April 2008. 2583 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 2584 Key Derivation Function (HKDF)", RFC 5869, 2585 DOI 10.17487/RFC5869, May 2010, 2586 . 2588 [RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a 2589 Prime (ECP Groups) for IKE and IKEv2", RFC 5903, 2590 DOI 10.17487/RFC5903, June 2010, 2591 . 2593 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2594 Curve Cryptography Algorithms", RFC 6090, 2595 DOI 10.17487/RFC6090, February 2011, 2596 . 2598 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2599 Constrained-Node Networks", RFC 7228, 2600 DOI 10.17487/RFC7228, May 2014, 2601 . 2603 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 2604 Kivinen, "Internet Key Exchange Protocol Version 2 2605 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2606 2014, . 2608 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 2609 for Security", RFC 7748, DOI 10.17487/RFC7748, January 2610 2016, . 2612 [RFC8005] Laganier, J., "Host Identity Protocol (HIP) Domain Name 2613 System (DNS) Extension", RFC 8005, DOI 10.17487/RFC8005, 2614 October 2016, . 2616 Appendix A. Password-based two-factor authentication during the HIP DEX 2617 handshake 2619 HIP DEX allows identifying authorized connections based on a two- 2620 factor authentication mechanism. With two-factor authentication, 2621 devices that are authorized to communicate with each other are 2622 required to be pre-provisioned with a shared (group) key. The 2623 Initiator uses this pre-provisioned key to encrypt the 2624 ECHO_RESPONSE_UNSIGNED in the I2 packet. Upon reception of the I2, 2625 the Responder verifies that its challenge in the 2626 ECHO_REQUEST_UNSIGNED parameter in the R1 packet has been encrypted 2627 with the correct key. If verified successfully, the Responder 2628 proceeds with the handshake. Otherwise, it silently drops the I2 2629 packet. 2631 Note that there is no explicit signaling in the HIP DEX handshake for 2632 this behavior. Thus, knowledge of two-factor authentication must be 2633 configured externally prior to the handshake. 2635 Appendix B. IESG Considerations 2637 During IESG review, a concern was raised on the number of SHOULDS in 2638 this document. Here is an analysis of the 57 SHOULDS in HIP DEX. 2640 46 of SHOULDS are also in [RFC7401]. Here are the sections with 2641 SHOULDS that match up with [RFC7401]: 2643 5.2.2. HIP_CIPHER (same as 7401) 2645 6.5. Processing Incoming I1 Packets 2646 3. (same as 7401) 2647 5. (same as 7401) 2649 6.6. Processing Incoming R1 Packets (same as 7401) 2651 6.7. Processing Incoming I2 Packets 2652 3. (same as 7401) 2653 7. (same as 7401) 2654 11. (same as 7401) 2656 6.8. Processing Incoming R2 Packets 2657 5. (same as 7401) 2659 6.9. Processing Incoming NOTIFY Packets 2660 1st para (same as 7401) 2662 6.11. Handling State Loss (same as 7401) 2664 7. HIP Policies (1st and 3rd same as 7401) 2666 Many of the other 11 SHOULDS are due to the nature of constrained 2667 devices and in most cases the text points this out: 2669 In Section 4.1.1, this is clearly adjusting for how the puzzle could 2670 actually be an attack against a constrained device. Same situation 2671 in Section 5.3.2. 2673 Section 6, clearly states that: 2675 it should be noted that many of the packet processing rules are 2676 denoted here with "SHOULD" but may be updated to "MUST" when 2677 further implementation experience provides better guidance. 2679 thus the SHOULD here is informative of future guidance. 2681 The SHOULD in Section 6.3, clearly reflects new work with the new 2682 Sponge Function KDFs: 2684 The keys derived for the Pair-wise Key SA are not used during the HIP 2685 DEX handshake. Instead, these keys are made available as payload 2686 protection keys (e.g., for IPsec). Some payload protection 2687 mechanisms have their own Key Derivation Function, and if so this 2688 mechanism SHOULD be used. Otherwise, the HIP DEX KEYMAT process MUST 2689 be used to derive the keys of the Pair-wise Key SA based on the 2690 concatenation of the random values that are contained in the 2691 exchanged ENCRYPTED_KEY parameters. 2693 In Section 6.5, the reason why this is a SHOULD should be clear to 2694 any implementer. That is the HIT Suite list in I1 is a desire on 2695 what suite to use. The Responder may have 'different ideas' about 2696 the Suite to use (like what it supports). Thus it is best that the 2697 Responder selects a DEX HIT, but there are good reasons, in an 2698 implementation not to do so. The implementer should know this and 2699 will deal with it appropriately. 2701 The SHOULDs in Section 6.7 and Section 6.9 are there for 2702 considerations for constrained systems. Some constrained systems 2703 need this approach, others may not. 2705 The 2nd SHOULD in Section 7 follows the same as above. ACLs and 2706 constrained systems tend to go together. 2708 Similarly in Section 8 the SHOULD is again is highlighting 2709 constrained system processing considerations. 2711 Authors' Addresses 2713 Robert Moskowitz (editor) 2714 HTT Consulting 2715 Oak Park, MI 2716 USA 2718 EMail: rgm@htt-consult.com 2720 Rene Hummen 2721 Hirschmann Automation and Control 2722 Stuttgarter Strasse 45-51 2723 Neckartenzlingen 72654 2724 Germany 2726 EMail: rene.hummen@belden.com 2728 Miika Komu 2729 Ericsson Research, Finland 2730 Hirsalantie 11 2731 Jorvas 02420 2732 Finland 2734 EMail: miika.komu@ericsson.com