idnits 2.17.1 draft-farinacci-lisp-crypto-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 90: '...for key exchange MUST be one round-tri...' RFC 2119 keyword, line 289: '...the RLOC-set, it MUST send a Map-Reque...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2014) is 3567 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-05) exists of draft-mcgrew-aead-aes-cbc-hmac-sha2-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-04 == Outdated reference: A later version (-04) exists of draft-fuller-lisp-ddt-03 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-06 Summary: 4 errors (**), 0 flaws (~~), 5 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 July 20, 2014 5 Expires: January 21, 2015 7 LISP Data-Plane Confidentiality 8 draft-farinacci-lisp-crypto-01 10 Abstract 12 This document describes a mechanism for encrypting LISP encapsulated 13 traffic. The design describes how key exchange is achieved using 14 existing LISP control-plane mechanisms as well as how to secure the 15 LISP data-plane from third-party surveillance attacks. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 21, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 3 54 4. Encoding and Transmitting Key Material . . . . . . . . . . . 4 55 5. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . 6 56 6. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . 6 57 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 8.1. SAAG Support . . . . . . . . . . . . . . . . . . . . . . 7 60 8.2. LISP-Crypto Security Threats . . . . . . . . . . . . . . 8 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 10.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 9 66 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 10 67 B.1. Changes to draft-farinacci-lisp-crypto-01.txt . . . . . . 10 68 B.2. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 10 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction 73 The Locator/ID Separation Protocol [RFC6830] defines a set of 74 functions for routers to exchange information used to map from non- 75 routable Endpoint Identifiers (EIDs) to routable Routing Locators 76 (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. 77 Packets that arrive at the ITR or PITR are typically not modified. 78 Which means no protection or privacy of the data is added. If the 79 source host encrypts the data stream then the encapsulated packets 80 can be encrypted but would be redundant. However, when plaintext 81 packets are sent by hosts, this design can encrypt the user payload 82 to maintain privacy on the path between the encapsulator (the ITR or 83 PITR) to a decapsulator (ETR or RTR). 85 This draft has the following requirements for the solution space: 87 o Do not require a separate Public Key Infrastructure (PKI) that is 88 out of scope of the LISP control-plane architecture. 90 o The budget for key exchange MUST be one round-trip time. That is, 91 only a two packet exchange can occur. 93 o Use symmetric keying so faster cryptography can be performed in 94 the LISP data plane. 96 o Avoid a third-party trust anchor if possible. 98 o Provide for rekeying when secret keys are compromised. 100 o At this time, encapsulated packet authentication is not a strong 101 requirement. 103 2. Overview 105 The approach proposed in this draft is to not rely on the LISP 106 mapping system to store security keys. This will provide for a 107 simpler and more secure mechanism. Secret shared keys will be 108 negotiated between the ITR and the ETR in Map-Request and Map-Reply 109 messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, 110 it will get security material to compute a shared secret with the 111 ETR. 113 The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating 114 to. And when the ITR encrypts a packet before encapsulation, it will 115 identify the key it used for the crypto calculation so the ETR knows 116 which key to use for decrypting the packet after decapsulation. By 117 using key-ids in the LISP header, we can also get rekeying 118 functionality. 120 3. Diffie-Hellman Key Exchange 122 LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and 123 computation for computing a shared secret. The Diffie-Hellman 124 parameters will be passed in Map-Request and Map-Reply messages. 126 Here is a brief description how Diff-Hellman works: 128 +----------------------------+---------+----------------------------+ 129 | ITR | | ETR | 130 +------+--------+------------+---------+------------+---------------+ 131 |Secret| Public | Calculates | Sends | Calculates | Public |Secret| 132 +------|--------|------------|---------|------------|--------|------+ 133 | i | p,g | | p,g --> | | | e | 134 +------|--------|------------|---------|------------|--------|------+ 135 | i | p,g,I |g^i mod p=I | I --> | | p,g,I | e | 136 +------|--------|------------|---------|------------|--------|------+ 137 | i | p,g,I | | <-- E |g^e mod p=E | p,g | e | 138 +------|--------|------------|---------|------------|--------|------+ 139 | i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s | 140 +------|--------|------------|---------|------------|--------|------+ 142 Public-key exchange for computing a shared private key [DH] 144 Diffie-Hellman parameters 'p' and 'g' must be the same values used by 145 the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' 146 in a Map-Request packet. When the ETR receives the Map-Request, it 147 uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The 148 ETR transmits 'E' in a Map-Reply message. At this point, the ETR has 149 enough information to compute 's', the shared secret, by using 'I' as 150 the base and the ETR's private key 'e' as the exponent. When the ITR 151 receives the Map-Reply, it uses the ETR's public-key 'E' with the 152 ITR's private key 'i' to compute the same 's' shared secret the ETR 153 computed. The value 'p' is used as a modulus to create the width of 154 the shared secret 's'. 156 4. Encoding and Transmitting Key Material 158 The Diffie-Hellman key material is transmitted in Map-Request and 159 Map-Reply messages. Diffie-Hellman parameters are encoded in the 160 LISP Security Type LCAF [LCAF]. 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | AFI = 16387 | Rsvd1 | Flags | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Type = 11 | Rsvd2 | 6 + n | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Key Length | Key Material ... | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | ... Key Material | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | AFI = x | Locator Address ... | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Diffie-Hellman parameters encoded in Key Material field 180 The 'Key Count' field encodes the number of {'Key-Length', 'Key- 181 Material'} fields included in the encoded LCAF. A maximum number of 182 keys that can be encoded are 3 keys, each identified by key-id 1, 183 followed by key-id 2, an finally key-id 3. 185 The 'R' bit is not used for this use-case of the Security Type LCAF 186 but is reserved for [LISP-DDT] security. 188 The 'Key Algorithm' encodes the cryptographic algorithm used. The 189 following values are defined: 191 Null: 0 192 Group-ID: 1 193 AES: 2 194 3DES: 3 195 SHA-256: 4 197 When the 'Key Algorithm' value is 1 (Group-ID), the 'Key Material' 198 field is encoded as: 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Group ID | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Public Key ... | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Points to Key Material values from IANA Registry 210 The Group-ID values are defined in [RFC2409] and [RFC3526] which 211 describe the Diffie Hellman parameters used for key exchange. 213 When the 'Key Algorithm' value is not 1 (Group-ID), the 'Key 214 Material' field is encoded as: 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | g-length | g-value ... | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | p-length | p-value ... | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Public Key ... | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Key Length describes the length of the Key Material field 228 When an ITR or PITR sends a Map-Request, they will encode their own 229 RLOC in Security Type LCAF format within the ITR-RLOCs field. When a 230 ETR or RTR sends a Map-Reply, they will encode their RLOCs in 231 Security Type LCAF format within the RLOC-record field of each EID- 232 record supplied. 234 If an ITR or PITR sends a Map-Request with a Security Type LCAF 235 included and the ETR or RTR does not want to have encapsulated 236 traffic encrypted, they will return a Map-Reply with no RLOC records 237 encoded with the Security Type LCAF. This signals to the ITR or PITR 238 that it should not encrypt traffic (it cannot encrypt traffic anyways 239 since no ETR public-key was returned). 241 Likewise, if an ITR or PITR wish to include multiple key-ids in the 242 Map-Request but the ETR or RTR wish to use some but not all of the 243 key-ids, they return a Map-Reply only for those key-ids they wish to 244 use. 246 5. Data-Plane Operation 248 The LISP encapsulation header [RFC6830] requires changes to encode 249 the key-id for the key being used for encryption. 251 0 1 2 3 252 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 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 / | Source Port = xxxx | Dest Port = 4341 | 255 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 \ | UDP Length | UDP Checksum | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 L |N|L|E|V|I|P|K|K| Nonce/Map-Version | 259 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 S / | Instance ID/Locator-Status-Bits | 261 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 K-bits indicate when packet is encrypted and which key used 265 When the KK bits are 00, the encapsulated packet is not encrypted. 266 When the value of the KK bits is 1, 2, or 3, it encodes the key-id of 267 the secret keys computed during the Diffie-Hellman Map-Request/Map- 268 Reply exchange. 270 When an ITR or PITR receives a packet to be encapsulated, they will 271 first decide what key to use, encode the key-id into the LISP header, 272 and use that key to encrypt all packet data that follows the LISP 273 header. Therefore, the outer header, UDP header, and LISP header 274 travel as plaintext. 276 6. Dynamic Rekeying 278 Since multiple keys can be encoded in both control and data messages, 279 an ITR can encapsulate and encrypt with a specific key while it is 280 negotiating other keys with the same ETR. Soon as an ETR or RTR 281 returns a Map-Reply, it should be prepared to decapsulate and decrypt 282 using the new keys computed with the new Diffie-Hellman parameters 283 received in the Map-Request and returned in the Map-Reply. 285 RLOC-probing can be used to change keys by the ITR at any time. And 286 when an initial Map-Request is sent to populate the ITR's map-cache, 287 the Map-Requests flows across the mapping system where a single ETR 288 from the Map-Reply RLOC-set will respond. If the ITR decides to use 289 the other RLOCs in the RLOC-set, it MUST send a Map-Request directly 290 to key negotiate with the ETR. This process may be used to test 291 reachability from an ITR to an ETR initially when a map-cache entry 292 is added for the first time, so an ITR can get both reachability 293 status and keys negotiated with one Map-Request/Map-Reply exchange. 295 A rekeying event is defined to be when an ITR or PITR changes the p, 296 g, or the public-key in a Map-Request. The ETR or RTR compares the 297 p, g, and public-key it last received from the ITR for the key-id, 298 and if any value has changed, it computes a new public-key of its own 299 with the new p and g values from the Map-Request and returns it in 300 the Map-Reply. Now a new shared secret is computed and can be used 301 for the key-id for encryption by the ITR and decryption by the ETR. 302 When the ITR or PITR starts this process of negotiating a new key, it 303 must not use the corresponding key-id in encapsulated packets until 304 it receives a Map-Reply from the ETR with the p and g values it 305 expects (the values it sent in a Map-Request). 307 Note when RLOC-probing continues to maintain RLOC reachability and 308 rekeying is not desirable, the ITR or RTR can either not include the 309 Security Type LCAF in the Map-Request or supply the same key material 310 as it recieved from the last Map-Reply from the ETR or RTR. This 311 approach signals to the ETR or RTR that no rekeying event is 312 requested. 314 7. Future Work 316 By using AES-GCM [RFC5116], or HMAC-CBC [AES-CBC], it has been 317 suggested that encapsulated packet authentication (through encryption 318 [RFC4106]) could be supported. There is current work in progress to 319 investigate these techniques for the LISP data-plane. However, it 320 will require encapsulation header changes to LISP. 322 For performance considerations, Elliptic-Curve Diffie Hellman (ECDH) 323 can be used as specified in [RFC4492] to reduce CPU cycles required 324 to compute shared secret keys. 326 8. Security Considerations 328 8.1. SAAG Support 330 The LISP working group will seek help from the SAAG working group for 331 security advice. The SAAG will be involved early in the design 332 process so they have early input and review. 334 8.2. LISP-Crypto Security Threats 336 Since ITRs and ETRs participate in key exchange over a public non- 337 secure network, a man-in-the-middle (MITM) could circumvent the key 338 exhange and compromise data-plane confidentiality. This can happen 339 when the MITM is acting as a Map-Replier, provides its own public key 340 so the ITR and the MITM generate a shared secret key among each 341 other. If the MITM is in the data path between the ITR and ETR, it 342 can use the shared secret key to decrypt traffic from the ITR. 344 Since LISP can secure Map-Replies by the authentication process 345 specified in [LISP-SEC], the ITR can detect when a MITM has signed a 346 Map-Reply for an EID-prefix it is not authoritative for. When an ITR 347 determines the signature verification fails, it discards and does not 348 reuse the key exchange parameters, avoids using the ETR for 349 encapsulation, and issues a severe log message to the network 350 adminstrator. Optionally, the ITR can send RLOC-probes to the 351 compromised RLOC to determine if can reach the authoriative ETR. And 352 when the ITR validates the signature of a Map-Reply, it can begin 353 encrypting and encapsulating packets to the RLOC of ETR. 355 9. IANA Considerations 357 This draft requires the use of the registry that selects Diffie 358 Hellman parameters. Rather than convey the key exchange parameters 359 directly in LISP control packets, a Group-ID from the registry will 360 be used. The Group-ID values are defined in [RFC2409] and [RFC3526]. 362 10. References 364 10.1. Normative References 366 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 367 (IKE)", RFC 2409, November 1998. 369 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 370 2631, June 1999. 372 [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) 373 Diffie-Hellman groups for Internet Key Exchange (IKE)", 374 RFC 3526, May 2003. 376 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 377 (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC 378 4106, June 2005. 380 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 381 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 382 for Transport Layer Security (TLS)", RFC 4492, May 2006. 384 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 385 Encryption", RFC 5116, January 2008. 387 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 388 Locator/ID Separation Protocol (LISP)", RFC 6830, January 389 2013. 391 10.2. Informative References 393 [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated 394 Encryption with AES-CBC and HMAC-SHA", draft-mcgrew-aead- 395 aes-cbc-hmac-sha2-03.txt (work in progress), . 397 [DH] "Diffie-Hellman key exchange", Wikipedia 398 http://en.wikipedia.org/wiki/Diffie-Hellman_key_exchange, 399 . 401 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 402 Address Format", draft-ietf-lisp-lcaf-04.txt (work in 403 progress), . 405 [LISP-DDT] 406 Fuller, V., Lewis, D., Ermaagan, V., and A. Jain, "LISP 407 Delegated Database Tree", draft-fuller-lisp-ddt-03 (work 408 in progress), . 410 [LISP-SEC] 411 Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, 412 "LISP-Secuirty (LISP-SEC)", draft-ietf-lisp-sec-06 (work 413 in progress), . 415 Appendix A. Acknowledgments 417 The author would like to thank Dan Harkins, Brian Weis, Joel Halpern, 418 Fabio Maino, Ed Lopez, and Roger Jorgensen for their interest, 419 suggestions, and discussions about LISP data-plane security. 421 In addition, the support and suggestions from the SAAG working group 422 were helpful and appreciative. 424 Appendix B. Document Change Log 426 B.1. Changes to draft-farinacci-lisp-crypto-01.txt 428 o Posted July 2014. 430 o Add Group-ID to the encoding format of Key Material in a Security 431 Type LCAF and modify the IANA Considerations so this draft can use 432 key exchange parameters from the IANA registry. 434 o Indicate that the R-bit in the Security Type LCAF is not used by 435 lisp-crypto. 437 o Add text to indicate that ETRs/RTRs can negotiate less number of 438 keys from which the ITR/PITR sent in a Map-Request. 440 o Add text explaining how LISP-SEC solves the problem when a man-in- 441 the-middle becomes part of the Map-Request/Map-Reply key exchange 442 process. 444 o Add text indicating that when RLOC-probing is used for RLOC 445 reachability purposes and rekeying is not desired, that the same 446 key exchange parameters should be used so a reallocation of a 447 pubic key does not happen at the ETR. 449 o Add text to indicate that ECDH can be used to reduce CPU 450 requirements for computing shared secret-keys. 452 B.2. Changes to draft-farinacci-lisp-crypto-00.txt 454 o Initial draft posted February 2014. 456 Author's Address 458 Dino Farinacci 459 lispers.net 460 San Jose, California 461 USA 463 Phone: 408-718-2001 464 Email: farinacci@gmail.com