idnits 2.17.1 draft-ietf-lisp-crypto-06.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 (June 29, 2016) is 2858 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-13 ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-10 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force D. Farinacci 3 Internet-Draft lispers.net 4 Intended status: Experimental B. Weis 5 Expires: December 31, 2016 cisco Systems 6 June 29, 2016 8 LISP Data-Plane Confidentiality 9 draft-ietf-lisp-crypto-06 11 Abstract 13 This document describes a mechanism for encrypting LISP encapsulated 14 traffic. The design describes how key exchange is achieved using 15 existing LISP control-plane mechanisms as well as how to secure the 16 LISP data-plane from third-party surveillance attacks. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 31, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 54 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4 57 6. Encoding and Transmitting Key Material . . . . . . . . . . . 5 58 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 7 59 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 9 60 9. Procedures for Encryption and Decryption . . . . . . . . . . 10 61 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 11 62 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 12 65 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 12 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 67 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 14.2. Informative References . . . . . . . . . . . . . . . . . 15 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 71 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 16 72 B.1. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 16 73 B.2. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 16 74 B.3. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 16 75 B.4. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 16 76 B.5. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 17 77 B.6. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 17 78 B.7. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 17 79 B.8. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 17 80 B.9. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The Locator/ID Separation Protocol [RFC6830] defines a set of 86 functions for routers to exchange information used to map from non- 87 routable Endpoint Identifiers (EIDs) to routable Routing Locators 88 (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. 89 Packets that arrive at the ITR or PITR are typically not modified. 90 Which means no protection or privacy of the data is added. If the 91 source host encrypts the data stream then the encapsulated packets 92 can be encrypted but would be redundant. However, when plaintext 93 packets are sent by hosts, this design can encrypt the user payload 94 to maintain privacy on the path between the encapsulator (the ITR or 95 PITR) to a decapsulator (ETR or RTR). The encrypted payload is 96 unidirectional. However, return traffic uses the same procedures but 97 with different key values by the same xTRs or potentially different 98 xTRs when the paths between LISP sites are asymmetric. 100 This document has the following requirements for the solution space: 102 o Do not require a separate Public Key Infrastructure (PKI) that is 103 out of scope of the LISP control-plane architecture. 105 o The budget for key exchange MUST be one round-trip time. That is, 106 only a two packet exchange can occur. 108 o Use symmetric keying so faster cryptography can be performed in 109 the LISP data plane. 111 o Avoid a third-party trust anchor if possible. 113 o Provide for rekeying when secret keys are compromised. 115 o Support Authenticated Encryption with packet integrity checks. 117 o Support multiple cipher suites so new crypto algorithms can be 118 easily introduced. 120 2. Requirements Notation 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Definition of Terms 128 AEAD: Authenticated Encryption with Additional Data. 130 ICV: Integrity Check Value. 132 4. Overview 134 The approach proposed in this document is to NOT rely on the LISP 135 mapping system (or any other key infrastructure system) to store 136 security keys. This will provide for a simpler and more secure 137 mechanism. Secret shared keys will be negotiated between the ITR and 138 the ETR in Map-Request and Map-Reply messages. Therefore, when an 139 ITR needs to obtain the RLOC of an ETR, it will get security material 140 to compute a shared secret with the ETR. 142 The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating 143 to. When the ITR encrypts a packet before encapsulation, it will 144 identify the key it used for the crypto calculation so the ETR knows 145 which key to use for decrypting the packet after decapsulation. By 146 using key-ids in the LISP header, we can also get fast rekeying 147 functionality. 149 When an ETR (when it is also an ITR) encapsulates packets to this ITR 150 (when it is also an ETR), a separate key exchange and shared-secret 151 computation is performed. The key management described in this 152 documemnt is unidirectional from the ITR (the encapsulator) to the 153 ETR (the decapsultor). 155 5. Diffie-Hellman Key Exchange 157 LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and 158 computation for computing a shared secret. The Diffie-Hellman 159 parameters will be passed via Cipher Suite code-points in Map-Request 160 and Map-Reply messages. 162 Here is a brief description how Diff-Hellman works: 164 +----------------------------+---------+----------------------------+ 165 | ITR | | ETR | 166 +------+--------+------------+---------+------------+---------------+ 167 |Secret| Public | Calculates | Sends | Calculates | Public |Secret| 168 +------|--------|------------|---------|------------|--------|------+ 169 | i | p,g | | p,g --> | | | e | 170 +------|--------|------------|---------|------------|--------|------+ 171 | i | p,g,I |g^i mod p=I | I --> | | p,g,I | e | 172 +------|--------|------------|---------|------------|--------|------+ 173 | i | p,g,I | | <-- E |g^e mod p=E | p,g | e | 174 +------|--------|------------|---------|------------|--------|------+ 175 | i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s | 176 +------|--------|------------|---------|------------|--------|------+ 178 Public-key exchange for computing a shared private key [DH] 180 Diffie-Hellman parameters 'p' and 'g' must be the same values used by 181 the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' 182 in a Map-Request packet. When the ETR receives the Map-Request, it 183 uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The 184 ETR transmits 'E' in a Map-Reply message. At this point, the ETR has 185 enough information to compute 's', the shared secret, by using 'I' as 186 the base and the ETR's private key 'e' as the exponent. When the ITR 187 receives the Map-Reply, it uses the ETR's public-key 'E' with the 188 ITR's private key 'i' to compute the same 's' shared secret the ETR 189 computed. The value 'p' is used as a modulus to create the width of 190 the shared secret 's' (see Section 6). 192 6. Encoding and Transmitting Key Material 194 The Diffie-Hellman key material is transmitted in Map-Request and 195 Map-Reply messages. Diffie-Hellman parameters are encoded in the 196 LISP Security Type LCAF [LCAF]. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | AFI = 16387 | Rsvd1 | Flags | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Type = 11 | Rsvd2 | 6 + n | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R| 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Key Length | Public Key Material ... | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | ... Public Key Material | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | AFI = x | Locator Address ... | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions 216 The 'Key Count' field encodes the number of {'Key-Length', 'Key- 217 Material'} fields included in the encoded LCAF. The maximum number 218 of keys that can be encoded are 3, each identified by key-id 1, 219 followed by key-id 2, an finally key-id 3. 221 The 'R' bit is not used for this use-case of the Security Type LCAF 222 but is reserved for [LISP-DDT] security. Therefore, the R bit is 223 transmitted as 0 and ignored on receipt. 225 Cipher Suite 0: 226 Reserved 228 Cipher Suite 1: 229 Diffie-Hellman Group: 2048-bit MODP [RFC3526] 230 Encryption: AES with 128-bit keys in CBC mode [AES-CBC] 231 Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 232 IV length: 16 bytes 234 Cipher Suite 2: 235 Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] 236 Encryption: AES with 128-bit keys in CBC mode [AES-CBC] 237 Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 238 IV length: 16 bytes 240 Cipher Suite 3: 241 Diffie-Hellman Group: 2048-bit MODP [RFC3526] 242 Encryption: AES with 128-bit keys in GCM mode [RFC5116] 243 Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM 244 IV length: 12 bytes 246 Cipher Suite 4: 247 Diffie-Hellman Group: 3072-bit MODP [RFC3526] 248 Encryption: AES with 128-bit keys in GCM mode [RFC5116] 249 Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM 250 IV length: 12 bytes 252 Cipher Suite 5: 253 Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] 254 Encryption: AES with 128-bit keys in GCM mode [RFC5116] 255 Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM 256 IV length: 12 bytes 258 Cipher Suite 6: 259 Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] 260 Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] 261 Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305 262 IV length: 8 bytes 264 The "Public Key Material" field contains the public key generated by 265 one of the Cipher Suites defined above. The length of the key in 266 octets is encoded in the "Key Length" field. 268 When an ITR, PITR, or RTR sends a Map-Request, they will encode their 269 own RLOC in the Security Type LCAF format within the ITR-RLOCs field. 270 When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in 271 Security Type LCAF format within the RLOC-record field of each EID- 272 record supplied. 274 If an ITR, PITR, or RTR sends a Map-Request with the Security Type 275 LCAF included and the ETR or RTR does not want to have encapsulated 276 traffic encrypted, they will return a Map-Reply with no RLOC records 277 encoded with the Security Type LCAF. This signals to the ITR, PITR 278 or RTR not to encrypt traffic (it cannot encrypt traffic anyways 279 since no ETR public-key was returned). 281 Likewise, if an ITR or PITR wish to include multiple key-ids in the 282 Map-Request but the ETR or RTR wish to use some but not all of the 283 key-ids, they return a Map-Reply only for those key-ids they wish to 284 use. 286 7. Shared Keys used for the Data-Plane 288 When an ITR or PITR receives a Map-Reply accepting the Cipher Suite 289 sent in the Map-Request, it is ready to create data plane keys. The 290 same process is followed by the ETR or RTR returning the Map-Reply. 292 The first step is to create a shared secret, using the peer's shared 293 Diffie-Hellman Public Key Material combined with device's own private 294 keying material as described in Section 5. The Diffie-Hellman group 295 used is defined in the cipher suite sent in the Map-Request and 296 copied into the Map-Reply. 298 The resulting shared secret is used to compute an AEAD-key for the 299 algorithms specified in the cipher suite. A Key Derivation Function 300 (KDF) in counter mode as specified by [NIST-SP800-108] is used to 301 generate the data-plane keys. The amount of keying material that is 302 derived depends on the algorithms in the cipher suite. 304 The inputs to the KDF are as follows: 306 o KDF function. This is HMAC-SHA-256. 308 o A key for the KDF function. This is the computed Diffie-Hellman 309 shared secret. 311 o Context that binds the use of the data-plane keys to this session. 312 The context is made up of the following fields, which are 313 concatenated and provided as the data to be acted upon by the KDF 314 function. 316 Context: 318 o A counter, represented as a two-octet value in network-byte order. 320 o The null-terminated string "lisp-crypto". 322 o The ITR's nonce from the the Map-Request the cipher suite was 323 included in. 325 o The number of bits of keying material required (L), represented as 326 a two-octet value in network byte order. 328 The counter value in the context is first set to 1. When the amount 329 of keying material exceeds the number of bits returned by the KDF 330 function, then the KDF function is called again with the same inputs 331 except that the counter increments for each call. When enough keying 332 material is returned, it is concatenated and used to create keys. 334 For example, AES with 128-bit keys requires 16 octets (128 bits) of 335 keying material, and HMAC-SHA1-96 requires another 16 octets (128 336 bits) of keying material in order to maintain a consistent 128-bits 337 of security. Since 32 octets (256 bits) of keying material are 338 required, and the KDF function HMAC-SHA-256 outputs 256 bits, only 339 one call is required. The inputs are as follows: 341 key-material = HMAC-SHA-256(dh-shared-secret, context) 343 where: context = 0x0001 || "lisp-crypto" || || 0x0100 345 In contrast, a cipher suite specifying AES with 256-bit keys requires 346 32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires 347 another 32 octets (256 bits) of keying material in order to maintain 348 a consistent 256-bits of security. Since 64 octets (512 bits) of 349 keying material are required, and the KDF function HMAC-SHA-256 350 outputs 256 bits, two calls are required. 352 key-material-1 = HMAC-SHA-256(dh-shared-secret, context) 354 where: context = 0x0001 || "lisp-crypto" || || 0x0200 356 key-material-2 = HMAC-SHA-256(dh-shared-secret, context) 358 where: context = 0x0002 || "lisp-crypto" || || 0x0200 360 key-material = key-material-1 || key-material-2 362 If the key-material is longer than the required number of bits (L), 363 then only the most significant L bits are used. 365 From the derived key-material, the most significant 256 bits are used 366 for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided 367 into a 128-bit encryption key and a 128-bit integrity-check key 368 internal to the cipher used by the ITR. 370 8. Data-Plane Operation 372 The LISP encapsulation header [RFC6830] requires changes to encode 373 the key-id for the key being used for encryption. 375 0 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 / | Source Port = xxxx | Dest Port = 4341 | 379 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 \ | UDP Length | UDP Checksum | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 L / |N|L|E|V|I|R|K|K| Nonce/Map-Version |\ \ 383 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A 384 S \ | Instance ID/Locator-Status-Bits | |D 385 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/ 386 | Initialization Vector (IV) | I 387 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C 388 n / | | V 389 c | | | 390 r | Packet Payload with EID Header ... | | 391 y | | | 392 p \ | |/ 393 t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 K-bits indicate when packet is encrypted and which key used 397 When the KK bits are 00, the encapsulated packet is not encrypted. 398 When the value of the KK bits are 1, 2, or 3, it encodes the key-id 399 of the secret keys computed during the Diffie-Hellman Map-Request/ 400 Map-Reply exchange. When the KK bits are not 0, the payload is 401 prepended with an Initialization Vector (IV). The length of the IV 402 field is based on the cipher suite used. Since all cipher suites 403 defined in this document do Authenticated Encryption (AEAD), an ICV 404 field does not need to be present in the packet since it is included 405 in the ciphertext. The Additional Data (AD) used for the ICV is 406 shown above and includes the LISP header, the IV field and the packet 407 payload. 409 When an ITR or PITR receives a packet to be encapsulated, they will 410 first decide what key to use, encode the key-id into the LISP header, 411 and use that key to encrypt all packet data that follows the LISP 412 header. Therefore, the outer header, UDP header, and LISP header 413 travel as plaintext. 415 There is an open working group item to discuss if the data 416 encapsulation header needs change for encryption or any new 417 applications. This document proposes changes to the existing header 418 so experimentation can continue without making large changes to the 419 data-plane at this time. This document allocates 2 bits of the 420 previously unused 3 flag bits (note the R-bit above is still a 421 reserved flag bit) for the KK bits. 423 9. Procedures for Encryption and Decryption 425 When an ITR, PITR, or RTR encapsulate a packet and have already 426 computed an AEAD-key (detailed in section Section 7) that is 427 associated with a destination RLOC, the following encryption and 428 encapsulation procedures are performed: 430 1. The encapsulator creates an IV and prepends the IV value to the 431 packet being encapsulated. For GCM and Chacha cipher suites, the 432 IV is incremented for every packet (beginning with a value of 1 433 in the first packet) and sent to the destination RLOC. For CBC 434 cipher suites, the IV is a new random number for every packet 435 sent to the destination RLOC. For the Chacha cipher suite, the 436 IV is an 8-byte random value that is appended to a 4-byte counter 437 that is incremented for every packet (beginning with a value of 1 438 in the first packet). 440 2. Next encrypt with cipher function AES or Chacha20 using the AEAD- 441 key over the packet payload following the AEAD specification 442 referenced in the cipher suite definition. This does not include 443 the IV. The IV must be transmitted as plaintext so the decrypter 444 can use it as input to the decryption cipher. The payload should 445 be padded to an integral number of bytes a block cipher may 446 require. The result of the AEAD operation may contain an ICV, 447 the size of which is defined by the referenced AEAD 448 specification. Note that the AD (i.e. the LISP header exactly as 449 will be prepended in the next step and the IV) must be given to 450 the AEAD encryption function as the "associated data" argument. 452 3. Prepend the LISP header. The key-id field of the LISP header is 453 set to the key-id value that corresponds to key-pair used for the 454 encryption cipher. 456 4. Lastly, prepend the UDP header and outer IP header onto the 457 encrypted packet and send packet to destination RLOC. 459 When an ETR, PETR, or RTR receive an encapsulated packet, the 460 following decapsulation and decryption procedures are performed: 462 1. The outer IP header, UDP header, LISP header, and IV field are 463 stripped from the start of the packet. The LISP header and IV 464 are retained and given to the AEAD decryption operation as the 465 "associated data" argument. 467 2. The packet is decrypted using the AEAD-key and the IV from the 468 packet. The AEAD-key is obtained from a local-cache associated 469 with the key-id value from the LISP header. The result of the 470 decryption function is a plaintext packet payload if the cipher 471 returned a verified ICV. Otherwise, the packet has been tampered 472 with and is discarded. If the AEAD specification included an 473 ICV, the AEAD decryption function will locate the ICV in the 474 ciphertext and compare it to a version of the ICV that the AEAD 475 decryption function computes. If the computed ICV is different 476 than the ICV located in the ciphertext, then it will be 477 considered tampered. 479 3. If the packet was not tampered with, the decrypted packet is 480 forwarded to the destination EID. 482 10. Dynamic Rekeying 484 Since multiple keys can be encoded in both control and data messages, 485 an ITR can encapsulate and encrypt with a specific key while it is 486 negotiating other keys with the same ETR. Soon as an ETR or RTR 487 returns a Map-Reply, it should be prepared to decapsulate and decrypt 488 using the new keys computed with the new Diffie-Hellman parameters 489 received in the Map-Request and returned in the Map-Reply. 491 RLOC-probing can be used to change keys or cipher suites by the ITR 492 at any time. And when an initial Map-Request is sent to populate the 493 ITR's map-cache, the Map-Request flows across the mapping system 494 where a single ETR from the Map-Reply RLOC-set will respond. If the 495 ITR decides to use the other RLOCs in the RLOC-set, it MUST send a 496 Map-Request directly to negotiate security parameters with the ETR. 497 This process may be used to test reachability from an ITR to an ETR 498 initially when a map-cache entry is added for the first time, so an 499 ITR can get both reachability status and keys negotiated with one 500 Map-Request/Map-Reply exchange. 502 A rekeying event is defined to be when an ITR or PITR changes the 503 cipher suite or public-key in the Map-Request. The ETR or RTR 504 compares the cipher suite and public-key it last received from the 505 ITR for the key-id, and if any value has changed, it computes a new 506 public-key and cipher suite requested by the ITR from the Map-Request 507 and returns it in the Map-Reply. Now a new shared secret is computed 508 and can be used for the key-id for encryption by the ITR and 509 decryption by the ETR. When the ITR or PITR starts this process of 510 negotiating a new key, it must not use the corresponding key-id in 511 encapsulated packets until it receives a Map-Reply from the ETR with 512 the same cipher suite value it expects (the values it sent in a Map- 513 Request). 515 Note when RLOC-probing continues to maintain RLOC reachability and 516 rekeying is not desirable, the ITR or RTR can either not include the 517 Security Type LCAF in the Map-Request or supply the same key material 518 as it received from the last Map-Reply from the ETR or RTR. This 519 approach signals to the ETR or RTR that no rekeying event is 520 requested. 522 11. Future Work 524 For performance considerations, newer Elliptic-Curve Diffie-Hellman 525 (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to 526 reduce CPU cycles required to compute shared secret keys. 528 For better security considerations as well as to be able to build 529 faster software implementations, newer approaches to ciphers and 530 authentication methods will be researched and tested. Some examples 531 are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539]. 533 12. Security Considerations 535 12.1. SAAG Support 537 The LISP working group received security advice and guidance from the 538 Security Area Advisory Group (SAAG). The SAAG has been involved 539 early in the design process and their input and reviews have been 540 included in this document. 542 12.2. LISP-Crypto Security Threats 544 Since ITRs and ETRs participate in key exchange over a public non- 545 secure network, a man-in-the-middle (MITM) could circumvent the key 546 exchange and compromise data-plane confidentiality. This can happen 547 when the MITM is acting as a Map-Replier, provides its own public key 548 so the ITR and the MITM generate a shared secret key among each 549 other. If the MITM is in the data path between the ITR and ETR, it 550 can use the shared secret key to decrypt traffic from the ITR. 552 Since LISP can secure Map-Replies by the authentication process 553 specified in [LISP-SEC], the ITR can detect when a MITM has signed a 554 Map-Reply for an EID-prefix it is not authoritative for. When an ITR 555 determines the signature verification fails, it discards and does not 556 reuse the key exchange parameters, avoids using the ETR for 557 encapsulation, and issues a severe log message to the network 558 administrator. Optionally, the ITR can send RLOC-probes to the 559 compromised RLOC to determine if can reach the authoritative ETR. 560 And when the ITR validates the signature of a Map-Reply, it can begin 561 encrypting and encapsulating packets to the RLOC of ETR. 563 13. IANA Considerations 565 This document describes a mechanism for encrypting LISP encapsulated 566 packets based on Diffie-Hellman key exchange procedures. During the 567 exchange the devices have to agree on a Cipher Suite used (i.e. the 568 cipher and hash functions used to encrypt/decrypt and to sign/verify 569 packets). The 8-bit Cipher Suite field is reserved for such purpose 570 in the security material section of the Map-Request and Map-Reply 571 messages. 573 This document requests IANA to create and maintain a new registry (as 574 outlined in [RFC5226]) entitled "LISP Crypto Cipher Suite". Initial 575 values for the registry are provided below. Future assignments are 576 to be made on a First Come First Served Basis. 578 +-----+--------------------------------------------+------------+ 579 |Value| Suite | Definition | 580 +-----+--------------------------------------------+------------+ 581 | 0 | Reserved | Section 6 | 582 +-----+--------------------------------------------+------------+ 583 | 1 | LISP_2048MODP_AES128_CBC_SHA256 | Section 6 | 584 +-----+--------------------------------------------+------------+ 585 | 2 | LISP_EC25519_AES128_CBC_SHA256 | Section 6 | 586 +-----+--------------------------------------------+------------+ 587 | 3 | LISP_2048MODP_AES128_GCM | Section 6 | 588 +-----+--------------------------------------------+------------+ 589 | 4 | LISP_3072MODP_AES128_GCM M-3072 | Section 6 | 590 +-----+--------------------------------------------+------------+ 591 | 5 | LISP_256_EC25519_AES128_GCM | Section 6 | 592 +-----+--------------------------------------------+------------+ 593 | 6 | LISP_256_EC25519_CHACHA20_POLY1305 | Section 6 | 594 +-----+--------------------------------------------+------------+ 596 LISP Crypto Cipher Suites 598 14. References 600 14.1. Normative References 602 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 603 Address Format", draft-ietf-lisp-lcaf-13.txt (work in 604 progress). 606 [NIST-SP800-108] 607 "National Institute of Standards and Technology, 608 "Recommendation for Key Derivation Using Pseudorandom 609 Functions NIST SP800-108"", NIST SP 800-108, October 2009. 611 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 612 Requirement Levels", BCP 14, RFC 2119, 613 DOI 10.17487/RFC2119, March 1997, 614 . 616 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 617 RFC 2631, DOI 10.17487/RFC2631, June 1999, 618 . 620 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 621 Diffie-Hellman groups for Internet Key Exchange (IKE)", 622 RFC 3526, DOI 10.17487/RFC3526, May 2003, 623 . 625 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 626 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 627 for Transport Layer Security (TLS)", RFC 4492, 628 DOI 10.17487/RFC4492, May 2006, 629 . 631 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 632 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 633 . 635 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 636 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 637 DOI 10.17487/RFC5226, May 2008, 638 . 640 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 641 Curve Cryptography Algorithms", RFC 6090, 642 DOI 10.17487/RFC6090, February 2011, 643 . 645 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 646 Locator/ID Separation Protocol (LISP)", RFC 6830, 647 DOI 10.17487/RFC6830, January 2013, 648 . 650 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 651 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 652 . 654 14.2. Informative References 656 [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated 657 Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- 658 aes-cbc-hmac-sha2-05.txt (work in progress). 660 [CHACHA-POLY] 661 Langley, A., "ChaCha20 and Poly1305 based Cipher Suites 662 for TLS", draft-agl-tls-chacha20poly1305-04 (work in 663 progress). 665 [CURVE25519] 666 Bernstein, D., "Curve25519: new Diffie-Hellman speed 667 records", Publication 668 http://www.iacr.org/cryptodb/archive/2006/ 669 PKC/3351/3351.pdf. 671 [DH] "Diffie-Hellman key exchange", Wikipedia 672 http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. 674 [LISP-DDT] 675 Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP 676 Delegated Database Tree", draft-fuller-lisp-ddt-04 (work 677 in progress). 679 [LISP-SEC] 680 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 681 "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-10 (work 682 in progress). 684 Appendix A. Acknowledgments 686 The authors would like to thank Dan Harkins, Joel Halpern, Fabio 687 Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, 688 suggestions, and discussions about LISP data-plane security. An 689 individual thank you to LISP WG chair Luigi Iannone for shepherding 690 this document as well as contributing to the IANA Considerations 691 section. 693 The authors would like to give a special thank you to Ilari Liusvaara 694 for his extensive commentary and discussion. He has contributed his 695 security expertise to make lisp-crypto as secure as the state of the 696 art in cryptography. 698 In addition, the support and suggestions from the SAAG working group 699 were helpful and appreciative. 701 Appendix B. Document Change Log 703 [RFC Editor: Please delete this section on publication as RFC.] 705 B.1. Changes to draft-ietf-lisp-crypto-06.txt 707 o Posted June 2016. 709 o Fixed IDnits errors. 711 B.2. Changes to draft-ietf-lisp-crypto-05.txt 713 o Posted June 2016. 715 o Update document which reflects comments Luigi provided as document 716 shepherd. 718 B.3. Changes to draft-ietf-lisp-crypto-04.txt 720 o Posted May 2016. 722 o Update document timer from expiration. 724 B.4. Changes to draft-ietf-lisp-crypto-03.txt 726 o Posted December 2015. 728 o Changed cipher suite allocations. We now have 2 AES-CBC cipher 729 suites for compatibility, 3 AES-GCM cipher suites that are faster 730 ciphers that include AE and a Chacha20-Poly1305 cipher suite which 731 is the fastest but not totally proven/accepted.. 733 o Remove 1024-bit DH keys for key exchange. 735 o Make clear that AES and chacha20 ciphers use AEAD so part of 736 encrytion/decryption does authentication. 738 o Make it more clear that separate key pairs are used in each 739 direction between xTRs. 741 o Indicate that the IV length is different per cipher suite. 743 o Use a counter based IV for every packet for AEAD ciphers. 744 Previously text said to use a random number. But CBC ciphers, use 745 a random number. 747 o Indicate that key material is sent in network byte order (big 748 endian). 750 o Remove A-bit from Security Type LCAF. No need to do 751 authentication only with the introduction of AEAD ciphers. These 752 ciphers can do authentication. So you get ciphertext for free. 754 o Remove language that refers to "encryption-key" and "integrity- 755 key". Used term "AEAD-key" that is used by the AEAD cipher suites 756 that do encryption and authenticaiton internal to the cipher. 758 B.5. Changes to draft-ietf-lisp-crypto-02.txt 760 o Posted September 2015. 762 o Add cipher suite for Elliptic Curve 25519 DH exchange. 764 o Add cipher suite for Chacha20/Poly1305 ciphers. 766 B.6. Changes to draft-ietf-lisp-crypto-01.txt 768 o Posted May 2015. 770 o Create cipher suites and encode them in the Security LCAF. 772 o Add IV to beginning of packet header and ICV to end of packet. 774 o AEAD procedures are now part of encrpytion process. 776 B.7. Changes to draft-ietf-lisp-crypto-00.txt 778 o Posted January 2015. 780 o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- 781 00. This draft has become a working group document 783 o Add text to indicate the working group may work on a new data 784 encapsulation header format for data-plane encryption. 786 B.8. Changes to draft-farinacci-lisp-crypto-01.txt 788 o Posted July 2014. 790 o Add Group-ID to the encoding format of Key Material in a Security 791 Type LCAF and modify the IANA Considerations so this draft can use 792 key exchange parameters from the IANA registry. 794 o Indicate that the R-bit in the Security Type LCAF is not used by 795 lisp-crypto. 797 o Add text to indicate that ETRs/RTRs can negotiate less number of 798 keys from which the ITR/PITR sent in a Map-Request. 800 o Add text explaining how LISP-SEC solves the problem when a man-in- 801 the-middle becomes part of the Map-Request/Map-Reply key exchange 802 process. 804 o Add text indicating that when RLOC-probing is used for RLOC 805 reachability purposes and rekeying is not desired, that the same 806 key exchange parameters should be used so a reallocation of a 807 pubic key does not happen at the ETR. 809 o Add text to indicate that ECDH can be used to reduce CPU 810 requirements for computing shared secret-keys. 812 B.9. Changes to draft-farinacci-lisp-crypto-00.txt 814 o Initial draft posted February 2014. 816 Authors' Addresses 818 Dino Farinacci 819 lispers.net 820 San Jose, California 95120 821 USA 823 Phone: 408-718-2001 824 Email: farinacci@gmail.com 826 Brian Weis 827 cisco Systems 828 170 West Tasman Drive 829 San Jose, California 95124-1706 830 USA 832 Phone: 408-526-4796 833 Email: bew@cisco.com