idnits 2.17.1 draft-ietf-lisp-crypto-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 14, 2016) is 2303 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-lisp-lcaf has been published as RFC 8060 ** 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: draft-ietf-lisp-sec has been published as RFC 9303 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: April 17, 2017 cisco Systems 6 October 14, 2016 8 LISP Data-Plane Confidentiality 9 draft-ietf-lisp-crypto-10 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 April 17, 2017. 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 . . . . . . . . . . . . . . . . . . . . 4 54 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 4 57 6. Encoding and Transmitting Key Material . . . . . . . . . . . 5 58 7. Shared Keys used for the Data-Plane . . . . . . . . . . . . . 8 59 8. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 10 60 9. Procedures for Encryption and Decryption . . . . . . . . . . 11 61 10. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 12 62 11. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 64 12.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 13 65 12.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 14 66 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 14.1. Normative References . . . . . . . . . . . . . . . . . . 15 69 14.2. Informative References . . . . . . . . . . . . . . . . . 16 70 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 71 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 17 72 B.1. Changes to draft-ietf-lisp-crypto-10.txt . . . . . . . . 17 73 B.2. Changes to draft-ietf-lisp-crypto-09.txt . . . . . . . . 18 74 B.3. Changes to draft-ietf-lisp-crypto-08.txt . . . . . . . . 18 75 B.4. Changes to draft-ietf-lisp-crypto-07.txt . . . . . . . . 18 76 B.5. Changes to draft-ietf-lisp-crypto-06.txt . . . . . . . . 18 77 B.6. Changes to draft-ietf-lisp-crypto-05.txt . . . . . . . . 18 78 B.7. Changes to draft-ietf-lisp-crypto-04.txt . . . . . . . . 18 79 B.8. Changes to draft-ietf-lisp-crypto-03.txt . . . . . . . . 18 80 B.9. Changes to draft-ietf-lisp-crypto-02.txt . . . . . . . . 19 81 B.10. Changes to draft-ietf-lisp-crypto-01.txt . . . . . . . . 19 82 B.11. Changes to draft-ietf-lisp-crypto-00.txt . . . . . . . . 19 83 B.12. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 20 84 B.13. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 This document describes a mechanism for encrypting LISP encapsulated 90 traffic. The design describes how key exchange is achieved using 91 existing LISP control-plane mechanisms as well as how to secure the 92 LISP data-plane from third-party surveillance attacks. 94 The Locator/ID Separation Protocol [RFC6830] defines a set of 95 functions for routers to exchange information used to map from non- 96 routable Endpoint Identifiers (EIDs) to routable Routing Locators 97 (RLOCs). LISP Ingress Tunnel Routers (ITRs) and Proxy Ingress Tunnel 98 Routers (PITRs) encapsulate packets to Egress Tunnel Routers (ETRs) 99 and Reencapsulating Tunnel Routers (RTRs). Packets that arrive at 100 the ITR or PITR may not be encrypted, which means no protection or 101 privacy of the data is added. When the source host encrypts the data 102 stream, encapsulated packets do not need to be encrypted by LISP. 103 However, when plaintext packets are sent by hosts, this design can 104 encrypt the user payload to maintain privacy on the path between the 105 encapsulator (the ITR or PITR) to a decapsulator (ETR or RTR). The 106 encrypted payload is unidirectional. However, return traffic uses 107 the same procedures but with different key values by the same xTRs or 108 potentially different xTRs when the paths between LISP sites are 109 asymmetric. 111 This document has the following requirements (as well as the general 112 requirements from [RFC6973]) for the solution space: 114 o Do not require a separate Public Key Infrastructure (PKI) that is 115 out of scope of the LISP control-plane architecture. 117 o The budget for key exchange MUST be one round-trip time. That is, 118 only a two packet exchange can occur. 120 o Use symmetric keying so faster cryptography can be performed in 121 the LISP data plane. 123 o Avoid a third-party trust anchor if possible. 125 o Provide for rekeying when secret keys are compromised. 127 o Support Authenticated Encryption with packet integrity checks. 129 o Support multiple cipher suites so new crypto algorithms can be 130 easily introduced. 132 Satisfying the above requirements provides the following benefits: 134 o Avoiding a PKI reduces the operational cost of managing a secure 135 network. Key management is distributed and independent from any 136 other infrastructure. 138 o Packet transport is optimized due to less packet headers. Packet 139 loss is reduced by a more efficient key exchange. 141 o Authentication and privacy are provided with a single mechanism 142 thereby providing less per packet overhead and therefore more 143 resource efficiency. 145 2. Requirements Notation 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in [RFC2119]. 151 3. Definition of Terms 153 AEAD: Authenticated Encryption with Additional Data [RFC5116]. 155 ICV: Integrity Check Value. 157 LCAF: LISP Canonical Address Format ([LCAF]). 159 xTR: A general reference to ITRs, ETRs, RTRs, and PxTRs. 161 4. Overview 163 The approach proposed in this document is to NOT rely on the LISP 164 mapping system (or any other key infrastructure system) to store 165 security keys. This will provide for a simpler and more secure 166 mechanism. Secret shared keys will be negotiated between the ITR and 167 the ETR in Map-Request and Map-Reply messages. Therefore, when an 168 ITR needs to obtain the RLOC of an ETR, it will get security material 169 to compute a shared secret with the ETR. 171 The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating 172 to. When the ITR encrypts a packet before encapsulation, it will 173 identify the key it used for the crypto calculation so the ETR knows 174 which key to use for decrypting the packet after decapsulation. By 175 using key-ids in the LISP header, we can also get fast rekeying 176 functionality. 178 The key management described in this documemnt is unidirectional from 179 the ITR (the encapsulator) to the ETR (the decapsultor). 181 5. Diffie-Hellman Key Exchange 183 LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and 184 computation for computing a shared secret. The Diffie-Hellman 185 parameters will be passed via Cipher Suite code-points in Map-Request 186 and Map-Reply messages. 188 Here is a brief description how Diff-Hellman works: 190 +----------------------------+---------+----------------------------+ 191 | ITR | | ETR | 192 +------+--------+------------+---------+------------+---------------+ 193 |Secret| Public | Calculates | Sends | Calculates | Public |Secret| 194 +------|--------|------------|---------|------------|--------|------+ 195 | i | p,g | | p,g --> | | | e | 196 +------|--------|------------|---------|------------|--------|------+ 197 | i | p,g,I |g^i mod p=I | I --> | | p,g,I | e | 198 +------|--------|------------|---------|------------|--------|------+ 199 | i | p,g,I | | <-- E |g^e mod p=E | p,g | e | 200 +------|--------|------------|---------|------------|--------|------+ 201 | i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s | 202 +------|--------|------------|---------|------------|--------|------+ 204 Public-key exchange for computing a shared private key [DH] 206 Diffie-Hellman parameters 'p' and 'g' must be the same values used by 207 the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' 208 in a Map-Request packet. When the ETR receives the Map-Request, it 209 uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The 210 ETR transmits 'E' in a Map-Reply message. At this point, the ETR has 211 enough information to compute 's', the shared secret, by using 'I' as 212 the base and the ETR's private key 'e' as the exponent. When the ITR 213 receives the Map-Reply, it uses the ETR's public-key 'E' with the 214 ITR's private key 'i' to compute the same 's' shared secret the ETR 215 computed. The value 'p' is used as a modulus to create the width of 216 the shared secret 's' (see Section 6). 218 6. Encoding and Transmitting Key Material 220 The Diffie-Hellman key material is transmitted in Map-Request and 221 Map-Reply messages. Diffie-Hellman parameters are encoded in the 222 LISP Security Type LCAF [LCAF]. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | AFI = 16387 | Rsvd1 | Flags | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Type = 11 | Rsvd2 | 6 + n | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Key Count | Rsvd3 | Cipher Suite | Rsvd4 |R| 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Key Length | Public Key Material ... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | ... Public Key Material | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | AFI = x | Locator Address ... | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Cipher Suite field contains DH Key Exchange and Cipher/Hash Functions 242 The 'Key Count' field encodes the number of {'Key-Length', 'Key- 243 Material'} fields included in the encoded LCAF. The maximum number 244 of keys that can be encoded are 3, each identified by key-id 1, 245 followed by key-id 2, and finally key-id 3. 247 The 'R' bit is not used for this use-case of the Security Type LCAF 248 but is reserved for [LISP-DDT] security. Therefore, the R bit SHOULD 249 be transmitted as 0 and MUST be ignored on receipt. 251 Cipher Suite 0: 252 Reserved 254 Cipher Suite 1: 255 Diffie-Hellman Group: 2048-bit MODP [RFC3526] 256 Encryption: AES with 128-bit keys in CBC mode [AES-CBC] 257 Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 258 IV length: 16 bytes 259 KDF: HMAC-SHA-256 261 Cipher Suite 2: 262 Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] 263 Encryption: AES with 128-bit keys in CBC mode [AES-CBC] 264 Integrity: Integrated with [AES-CBC] AEAD_AES_128_CBC_HMAC_SHA_256 265 IV length: 16 bytes 266 KDF: HMAC-SHA-256 268 Cipher Suite 3: 269 Diffie-Hellman Group: 2048-bit MODP [RFC3526] 270 Encryption: AES with 128-bit keys in GCM mode [RFC5116] 271 Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM 272 IV length: 12 bytes 273 KDF: HMAC-SHA-256 275 Cipher Suite 4: 276 Diffie-Hellman Group: 3072-bit MODP [RFC3526] 277 Encryption: AES with 128-bit keys in GCM mode [RFC5116] 278 Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM 279 IV length: 12 bytes 280 KDF: HMAC-SHA-256 282 Cipher Suite 5: 283 Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] 284 Encryption: AES with 128-bit keys in GCM mode [RFC5116] 285 Integrity: Integrated with [RFC5116] AEAD_AES_128_GCM 286 IV length: 12 bytes 287 KDF: HMAC-SHA-256 289 Cipher Suite 6: 290 Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519] 291 Encryption: Chacha20-Poly1305 [CHACHA-POLY] [RFC7539] 292 Integrity: Integrated with [CHACHA-POLY] AEAD_CHACHA20_POLY1305 293 IV length: 8 bytes 294 KDF: HMAC-SHA-256 296 The "Public Key Material" field contains the public key generated by 297 one of the Cipher Suites defined above. The length of the key in 298 octets is encoded in the "Key Length" field. 300 When an ITR, PITR, or RTR sends a Map-Request, they will encode their 301 own RLOC in the Security Type LCAF format within the ITR-RLOCs field. 302 When a ETR or RTR sends a Map-Reply, they will encode their RLOCs in 303 Security Type LCAF format within the RLOC-record field of each EID- 304 record supplied. 306 If an ITR, PITR, or RTR sends a Map-Request with the Security Type 307 LCAF included and the ETR or RTR does not want to have encapsulated 308 traffic encrypted, they will return a Map-Reply with no RLOC records 309 encoded with the Security Type LCAF. This signals to the ITR, PITR 310 or RTR not to encrypt traffic (it cannot encrypt traffic anyways 311 since no ETR public-key was returned). 313 Likewise, if an ITR or PITR wish to include multiple key-ids in the 314 Map-Request but the ETR or RTR wish to use some but not all of the 315 key-ids, they return a Map-Reply only for those key-ids they wish to 316 use. 318 7. Shared Keys used for the Data-Plane 320 When an ITR or PITR receives a Map-Reply accepting the Cipher Suite 321 sent in the Map-Request, it is ready to create data plane keys. The 322 same process is followed by the ETR or RTR returning the Map-Reply. 324 The first step is to create a shared secret, using the peer's shared 325 Diffie-Hellman Public Key Material combined with device's own private 326 keying material as described in Section 5. The Diffie-Hellman 327 parameters used is defined in the cipher suite sent in the Map- 328 Request and copied into the Map-Reply. 330 The resulting shared secret is used to compute an AEAD-key for the 331 algorithms specified in the cipher suite. A Key Derivation Function 332 (KDF) in counter mode as specified by [NIST-SP800-108] is used to 333 generate the data-plane keys. The amount of keying material that is 334 derived depends on the algorithms in the cipher suite. 336 The inputs to the KDF are as follows: 338 o KDF function. This is HMAC-SHA-256 in this document but generally 339 specified in each Cipher Suite definition. 341 o A key for the KDF function. This is the computed Diffie-Hellman 342 shared secret. 344 o Context that binds the use of the data-plane keys to this session. 345 The context is made up of the following fields, which are 346 concatenated and provided as the data to be acted upon by the KDF 347 function. 349 Context: 351 o A counter, represented as a two-octet value in network byte order. 353 o The null-terminated string "lisp-crypto". 355 o The ITR's nonce from the Map-Request the cipher suite was included 356 in. 358 o The number of bits of keying material required (L), represented as 359 a two-octet value in network byte order. 361 The counter value in the context is first set to 1. When the amount 362 of keying material exceeds the number of bits returned by the KDF 363 function, then the KDF function is called again with the same inputs 364 except that the counter increments for each call. When enough keying 365 material is returned, it is concatenated and used to create keys. 367 For example, AES with 128-bit keys requires 16 octets (128 bits) of 368 keying material, and HMAC-SHA1-96 requires another 16 octets (128 369 bits) of keying material in order to maintain a consistent 128-bits 370 of security. Since 32 octets (256 bits) of keying material are 371 required, and the KDF function HMAC-SHA-256 outputs 256 bits, only 372 one call is required. The inputs are as follows: 374 key-material = HMAC-SHA-256(dh-shared-secret, context) 376 where: context = 0x0001 || "lisp-crypto" || || 0x0100 378 In contrast, a cipher suite specifying AES with 256-bit keys requires 379 32 octets (256 bits) of keying material, and HMAC-SHA256-128 requires 380 another 32 octets (256 bits) of keying material in order to maintain 381 a consistent 256-bits of security. Since 64 octets (512 bits) of 382 keying material are required, and the KDF function HMAC-SHA-256 383 outputs 256 bits, two calls are required. 385 key-material-1 = HMAC-SHA-256(dh-shared-secret, context) 387 where: context = 0x0001 || "lisp-crypto" || || 0x0200 389 key-material-2 = HMAC-SHA-256(dh-shared-secret, context) 391 where: context = 0x0002 || "lisp-crypto" || || 0x0200 393 key-material = key-material-1 || key-material-2 395 If the key-material is longer than the required number of bits (L), 396 then only the most significant L bits are used. 398 From the derived key-material, the most significant 256 bits are used 399 for the AEAD-key by AEAD ciphers. The 256-bit AEAD-key is divided 400 into a 128-bit encryption key and a 128-bit integrity check key 401 internal to the cipher used by the ITR. 403 8. Data-Plane Operation 405 The LISP encapsulation header [RFC6830] requires changes to encode 406 the key-id for the key being used for encryption. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 / | Source Port = xxxx | Dest Port = 4341 | 412 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 \ | UDP Length | UDP Checksum | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 L / |N|L|E|V|I|R|K|K| Nonce/Map-Version |\ \ 416 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A 417 S \ | Instance ID/Locator-Status-Bits | |D 418 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |/ 419 | Initialization Vector (IV) | I 420 E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C 421 n / | | V 422 c | | | 423 r | Packet Payload with EID Header ... | | 424 y | | | 425 p \ | |/ 426 t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 K-bits indicate when packet is encrypted and which key used 430 When the KK bits are 00, the encapsulated packet is not encrypted. 431 When the value of the KK bits are 1, 2, or 3, it encodes the key-id 432 of the secret keys computed during the Diffie-Hellman Map-Request/ 433 Map-Reply exchange. When the KK bits are not 0, the payload is 434 prepended with an Initialization Vector (IV). The length of the IV 435 field is based on the cipher suite used. Since all cipher suites 436 defined in this document do Authenticated Encryption (AEAD), an ICV 437 field does not need to be present in the packet since it is included 438 in the ciphertext. The Additional Data (AD) used for the ICV is 439 shown above and includes the LISP header, the IV field and the packet 440 payload. 442 When an ITR or PITR receives a packet to be encapsulated, the device 443 will first decide what key to use, encode the key-id into the LISP 444 header, and use that key to encrypt all packet data that follows the 445 LISP header. Therefore, the outer header, UDP header, and LISP 446 header travel as plaintext. 448 There is an open working group item to discuss if the data 449 encapsulation header needs change for encryption or any new 450 applications. This document proposes changes to the existing header 451 so experimentation can continue without making large changes to the 452 data-plane at this time. This document allocates 2 bits of the 453 previously unused 3 flag bits (note the R-bit above is still a 454 reserved flag bit as documented in [RFC6830]) for the KK bits. 456 9. Procedures for Encryption and Decryption 458 When an ITR, PITR, or RTR encapsulate a packet and have already 459 computed an AEAD-key (detailed in section Section 7) that is 460 associated with a destination RLOC, the following encryption and 461 encapsulation procedures are performed: 463 1. The encapsulator creates an IV and prepends the IV value to the 464 packet being encapsulated. For GCM and Chacha cipher suites, the 465 IV is incremented for every packet (beginning with a value of 1 466 in the first packet) and sent to the destination RLOC. For CBC 467 cipher suites, the IV is a new random number for every packet 468 sent to the destination RLOC. For the Chacha cipher suite, the 469 IV is an 8-byte random value that is appended to a 4-byte counter 470 that is incremented for every packet (beginning with a value of 1 471 in the first packet). 473 2. Next encrypt with cipher function AES or Chacha20 using the AEAD- 474 key over the packet payload following the AEAD specification 475 referenced in the cipher suite definition. This does not include 476 the IV. The IV must be transmitted as plaintext so the decrypter 477 can use it as input to the decryption cipher. The payload should 478 be padded to an integral number of bytes a block cipher may 479 require. The result of the AEAD operation may contain an ICV, 480 the size of which is defined by the referenced AEAD 481 specification. Note that the AD (i.e. the LISP header exactly as 482 will be prepended in the next step and the IV) must be given to 483 the AEAD encryption function as the "associated data" argument. 485 3. Prepend the LISP header. The key-id field of the LISP header is 486 set to the key-id value that corresponds to key-pair used for the 487 encryption cipher. 489 4. Lastly, prepend the UDP header and outer IP header onto the 490 encrypted packet and send packet to destination RLOC. 492 When an ETR, PETR, or RTR receive an encapsulated packet, the 493 following decapsulation and decryption procedures are performed: 495 1. The outer IP header, UDP header, LISP header, and IV field are 496 stripped from the start of the packet. The LISP header and IV 497 are retained and given to the AEAD decryption operation as the 498 "associated data" argument. 500 2. The packet is decrypted using the AEAD-key and the IV from the 501 packet. The AEAD-key is obtained from a local-cache associated 502 with the key-id value from the LISP header. The result of the 503 decryption function is a plaintext packet payload if the cipher 504 returned a verified ICV. Otherwise, the packet is invalid and is 505 discarded. If the AEAD specification included an ICV, the AEAD 506 decryption function will locate the ICV in the ciphertext and 507 compare it to a version of the ICV that the AEAD decryption 508 function computes. If the computed ICV is different than the ICV 509 located in the ciphertext, then it will be considered tampered. 511 3. If the packet was not tampered with, the decrypted packet is 512 forwarded to the destination EID. 514 10. Dynamic Rekeying 516 Since multiple keys can be encoded in both control and data messages, 517 an ITR can encapsulate and encrypt with a specific key while it is 518 negotiating other keys with the same ETR. As soon as an ETR or RTR 519 returns a Map-Reply, it should be prepared to decapsulate and decrypt 520 using the new keys computed with the new Diffie-Hellman parameters 521 received in the Map-Request and returned in the Map-Reply. 523 RLOC-probing can be used to change keys or cipher suites by the ITR 524 at any time. And when an initial Map-Request is sent to populate the 525 ITR's map-cache, the Map-Request flows across the mapping system 526 where a single ETR from the Map-Reply RLOC-set will respond. If the 527 ITR decides to use the other RLOCs in the RLOC-set, it MUST send a 528 Map-Request directly to negotiate security parameters with the ETR. 530 This process may be used to test reachability from an ITR to an ETR 531 initially when a map-cache entry is added for the first time, so an 532 ITR can get both reachability status and keys negotiated with one 533 Map-Request/Map-Reply exchange. 535 A rekeying event is defined to be when an ITR or PITR changes the 536 cipher suite or public-key in the Map-Request. The ETR or RTR 537 compares the cipher suite and public-key it last received from the 538 ITR for the key-id, and if any value has changed, it computes a new 539 public-key and cipher suite requested by the ITR from the Map-Request 540 and returns it in the Map-Reply. Now a new shared secret is computed 541 and can be used for the key-id for encryption by the ITR and 542 decryption by the ETR. When the ITR or PITR starts this process of 543 negotiating a new key, it must not use the corresponding key-id in 544 encapsulated packets until it receives a Map-Reply from the ETR with 545 the same cipher suite value it expects (the values it sent in a Map- 546 Request). 548 Note when RLOC-probing continues to maintain RLOC reachability and 549 rekeying is not desirable, the ITR or RTR can either not include the 550 Security Type LCAF in the Map-Request or supply the same key material 551 as it received from the last Map-Reply from the ETR or RTR. This 552 approach signals to the ETR or RTR that no rekeying event is 553 requested. 555 11. Future Work 557 For performance considerations, newer Elliptic-Curve Diffie-Hellman 558 (ECDH) groups can be used as specified in [RFC4492] and [RFC6090] to 559 reduce CPU cycles required to compute shared secret keys. 561 For better security considerations as well as to be able to build 562 faster software implementations, newer approaches to ciphers and 563 authentication methods will be researched and tested. Some examples 564 are Chacha20 and Poly1305 [CHACHA-POLY] [RFC7539]. 566 12. Security Considerations 568 12.1. SAAG Support 570 The LISP working group received security advice and guidance from the 571 Security Area Advisory Group (SAAG). The SAAG has been involved 572 early in the design process and their input and reviews have been 573 included in this document. 575 Comments from the SAAG included: 577 1. Do not use asymmetric ciphers in the data-plane. 579 2. Consider adding ECDH early in the design. 581 3. Add cipher suites because ciphers are created more frequently 582 than protocols that use them. 584 4. Consider the newer AEAD technology so authentication comes with 585 doing encryption. 587 12.2. LISP-Crypto Security Threats 589 Since ITRs and ETRs participate in key exchange over a public non- 590 secure network, a man-in-the-middle (MITM) could circumvent the key 591 exchange and compromise data-plane confidentiality. This can happen 592 when the MITM is acting as a Map-Replier, provides its own public key 593 so the ITR and the MITM generate a shared secret key among each 594 other. If the MITM is in the data path between the ITR and ETR, it 595 can use the shared secret key to decrypt traffic from the ITR. 597 Since LISP can secure Map-Replies by the authentication process 598 specified in [LISP-SEC], the ITR can detect when a MITM has signed a 599 Map-Reply for an EID-prefix it is not authoritative for. When an ITR 600 determines the signature verification fails, it discards and does not 601 reuse the key exchange parameters, avoids using the ETR for 602 encapsulation, and issues a severe log message to the network 603 administrator. Optionally, the ITR can send RLOC-probes to the 604 compromised RLOC to determine if can reach the authoritative ETR. 605 And when the ITR validates the signature of a Map-Reply, it can begin 606 encrypting and encapsulating packets to the RLOC of ETR. 608 13. IANA Considerations 610 This document describes a mechanism for encrypting LISP encapsulated 611 packets based on Diffie-Hellman key exchange procedures. During the 612 exchange the devices have to agree on a Cipher Suite used (i.e. the 613 cipher and hash functions used to encrypt/decrypt and to sign/verify 614 packets). The 8-bit Cipher Suite field is reserved for such purpose 615 in the security material section of the Map-Request and Map-Reply 616 messages. 618 This document requests IANA to create and maintain a new registry (as 619 outlined in [RFC5226]) entitled "LISP Crypto Cipher Suite". Initial 620 values for the registry are provided below. Future assignments are 621 to be made on a First Come First Served Basis. 623 +-----+--------------------------------------------+------------+ 624 |Value| Suite | Definition | 625 +-----+--------------------------------------------+------------+ 626 | 0 | Reserved | Section 6 | 627 +-----+--------------------------------------------+------------+ 628 | 1 | LISP_2048MODP_AES128_CBC_SHA256 | Section 6 | 629 +-----+--------------------------------------------+------------+ 630 | 2 | LISP_EC25519_AES128_CBC_SHA256 | Section 6 | 631 +-----+--------------------------------------------+------------+ 632 | 3 | LISP_2048MODP_AES128_GCM | Section 6 | 633 +-----+--------------------------------------------+------------+ 634 | 4 | LISP_3072MODP_AES128_GCM M-3072 | Section 6 | 635 +-----+--------------------------------------------+------------+ 636 | 5 | LISP_256_EC25519_AES128_GCM | Section 6 | 637 +-----+--------------------------------------------+------------+ 638 | 6 | LISP_256_EC25519_CHACHA20_POLY1305 | Section 6 | 639 +-----+--------------------------------------------+------------+ 641 LISP Crypto Cipher Suites 643 14. References 645 14.1. Normative References 647 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 648 Address Format", draft-ietf-lisp-lcaf-13.txt (work in 649 progress). 651 [NIST-SP800-108] 652 "National Institute of Standards and Technology, 653 "Recommendation for Key Derivation Using Pseudorandom 654 Functions NIST SP800-108"", NIST SP 800-108, October 2009. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, 658 DOI 10.17487/RFC2119, March 1997, 659 . 661 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 662 RFC 2631, DOI 10.17487/RFC2631, June 1999, 663 . 665 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 666 Diffie-Hellman groups for Internet Key Exchange (IKE)", 667 RFC 3526, DOI 10.17487/RFC3526, May 2003, 668 . 670 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 671 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 672 for Transport Layer Security (TLS)", RFC 4492, 673 DOI 10.17487/RFC4492, May 2006, 674 . 676 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 677 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 678 . 680 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 681 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 682 DOI 10.17487/RFC5226, May 2008, 683 . 685 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 686 Curve Cryptography Algorithms", RFC 6090, 687 DOI 10.17487/RFC6090, February 2011, 688 . 690 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 691 Locator/ID Separation Protocol (LISP)", RFC 6830, 692 DOI 10.17487/RFC6830, January 2013, 693 . 695 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 696 Morris, J., Hansen, M., and R. Smith, "Privacy 697 Considerations for Internet Protocols", RFC 6973, 698 DOI 10.17487/RFC6973, July 2013, 699 . 701 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 702 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 703 . 705 14.2. Informative References 707 [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated 708 Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- 709 aes-cbc-hmac-sha2-05.txt (work in progress). 711 [CHACHA-POLY] 712 Langley, A., "ChaCha20 and Poly1305 based Cipher Suites 713 for TLS", draft-agl-tls-chacha20poly1305-04 (work in 714 progress). 716 [CURVE25519] 717 Bernstein, D., "Curve25519: new Diffie-Hellman speed 718 records", Publication 719 http://www.iacr.org/cryptodb/archive/2006/ 720 PKC/3351/3351.pdf. 722 [DH] "Diffie-Hellman key exchange", Wikipedia 723 http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. 725 [LISP-DDT] 726 Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP 727 Delegated Database Tree", draft-fuller-lisp-ddt-04 (work 728 in progress). 730 [LISP-SEC] 731 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 732 "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-10 (work 733 in progress). 735 Appendix A. Acknowledgments 737 The authors would like to thank Dan Harkins, Joel Halpern, Fabio 738 Maino, Ed Lopez, Roger Jorgensen, and Watson Ladd for their interest, 739 suggestions, and discussions about LISP data-plane security. An 740 individual thank you to LISP WG chair Luigi Iannone for shepherding 741 this document as well as contributing to the IANA Considerations 742 section. 744 The authors would like to give a special thank you to Ilari Liusvaara 745 for his extensive commentary and discussion. He has contributed his 746 security expertise to make lisp-crypto as secure as the state of the 747 art in cryptography. 749 In addition, the support and suggestions from the SAAG working group 750 were helpful and appreciative. 752 Appendix B. Document Change Log 754 [RFC Editor: Please delete this section on publication as RFC.] 756 B.1. Changes to draft-ietf-lisp-crypto-10.txt 758 o Posted October 2016 after October 13th telechat. 760 o Addressed comments from Kathleen Moriarty, Stephen Farrel, and 761 Pete Resnick. 763 B.2. Changes to draft-ietf-lisp-crypto-09.txt 765 o Posted October 2016. 767 o Addressed comments from OPs Directorate reviewer Susan Hares. 769 B.3. Changes to draft-ietf-lisp-crypto-08.txt 771 o Posted September 2016. 773 o Addressed comments from Security Directorate reviewer Chris 774 Lonvick. 776 B.4. Changes to draft-ietf-lisp-crypto-07.txt 778 o Posted September 2016. 780 o Addressed comments from Routing Directorate reviewer Danny 781 McPherson. 783 B.5. Changes to draft-ietf-lisp-crypto-06.txt 785 o Posted June 2016. 787 o Fixed IDnits errors. 789 B.6. Changes to draft-ietf-lisp-crypto-05.txt 791 o Posted June 2016. 793 o Update document which reflects comments Luigi provided as document 794 shepherd. 796 B.7. Changes to draft-ietf-lisp-crypto-04.txt 798 o Posted May 2016. 800 o Update document timer from expiration. 802 B.8. Changes to draft-ietf-lisp-crypto-03.txt 804 o Posted December 2015. 806 o Changed cipher suite allocations. We now have 2 AES-CBC cipher 807 suites for compatibility, 3 AES-GCM cipher suites that are faster 808 ciphers that include AE and a Chacha20-Poly1305 cipher suite which 809 is the fastest but not totally proven/accepted.. 811 o Remove 1024-bit DH keys for key exchange. 813 o Make clear that AES and chacha20 ciphers use AEAD so part of 814 encrytion/decryption does authentication. 816 o Make it more clear that separate key pairs are used in each 817 direction between xTRs. 819 o Indicate that the IV length is different per cipher suite. 821 o Use a counter based IV for every packet for AEAD ciphers. 822 Previously text said to use a random number. But CBC ciphers, use 823 a random number. 825 o Indicate that key material is sent in network byte order (big 826 endian). 828 o Remove A-bit from Security Type LCAF. No need to do 829 authentication only with the introduction of AEAD ciphers. These 830 ciphers can do authentication. So you get ciphertext for free. 832 o Remove language that refers to "encryption-key" and "integrity- 833 key". Used term "AEAD-key" that is used by the AEAD cipher suites 834 that do encryption and authenticaiton internal to the cipher. 836 B.9. Changes to draft-ietf-lisp-crypto-02.txt 838 o Posted September 2015. 840 o Add cipher suite for Elliptic Curve 25519 DH exchange. 842 o Add cipher suite for Chacha20/Poly1305 ciphers. 844 B.10. Changes to draft-ietf-lisp-crypto-01.txt 846 o Posted May 2015. 848 o Create cipher suites and encode them in the Security LCAF. 850 o Add IV to beginning of packet header and ICV to end of packet. 852 o AEAD procedures are now part of encrpytion process. 854 B.11. Changes to draft-ietf-lisp-crypto-00.txt 856 o Posted January 2015. 858 o Changing draft-farinacci-lisp-crypto-01 to draft-ietf-lisp-crypto- 859 00. This draft has become a working group document 861 o Add text to indicate the working group may work on a new data 862 encapsulation header format for data-plane encryption. 864 B.12. Changes to draft-farinacci-lisp-crypto-01.txt 866 o Posted July 2014. 868 o Add Group-ID to the encoding format of Key Material in a Security 869 Type LCAF and modify the IANA Considerations so this draft can use 870 key exchange parameters from the IANA registry. 872 o Indicate that the R-bit in the Security Type LCAF is not used by 873 lisp-crypto. 875 o Add text to indicate that ETRs/RTRs can negotiate less number of 876 keys from which the ITR/PITR sent in a Map-Request. 878 o Add text explaining how LISP-SEC solves the problem when a man-in- 879 the-middle becomes part of the Map-Request/Map-Reply key exchange 880 process. 882 o Add text indicating that when RLOC-probing is used for RLOC 883 reachability purposes and rekeying is not desired, that the same 884 key exchange parameters should be used so a reallocation of a 885 pubic key does not happen at the ETR. 887 o Add text to indicate that ECDH can be used to reduce CPU 888 requirements for computing shared secret-keys. 890 B.13. Changes to draft-farinacci-lisp-crypto-00.txt 892 o Initial draft posted February 2014. 894 Authors' Addresses 896 Dino Farinacci 897 lispers.net 898 San Jose, California 95120 899 USA 901 Phone: 408-718-2001 902 Email: farinacci@gmail.com 903 Brian Weis 904 cisco Systems 905 170 West Tasman Drive 906 San Jose, California 95124-1706 907 USA 909 Phone: 408-526-4796 910 Email: bew@cisco.com