idnits 2.17.1 draft-farinacci-lisp-crypto-00.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 87: '...for key exchange MUST be one round-tri...' RFC 2119 keyword, line 256: '...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 (February 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** 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 Summary: 2 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 February 14, 2014 5 Expires: August 18, 2014 7 LISP Data-Plane Confidentiality 8 draft-farinacci-lisp-crypto-00 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 August 18, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Diffie-Hellman Key Exchange . . . . . . . . . . . . . . . . . 5 54 4. Encoding and Transmitting Key Material . . . . . . . . . . . . 6 55 5. Data-Plane Operation . . . . . . . . . . . . . . . . . . . . . 8 56 6. Dynamic Rekeying . . . . . . . . . . . . . . . . . . . . . . . 9 57 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 62 10.2. Informative References . . . . . . . . . . . . . . . . . 13 63 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 64 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 15 65 B.1. Changes to draft-farinacci-lisp-crypto-00.txt . . . . . . 15 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 1. Introduction 70 The Locator/ID Separation Protocol [RFC6830] defines a set of 71 functions for routers to exchange information used to map from non- 72 routable Endpoint Identifiers (EIDs) to routable Routing Locators 73 (RLOCs). LISP ITRs and PITRs encapsulate packets to ETRs and RTRs. 74 Packets that arrive at the ITR or PITR are typically not modified. 75 Which means no protection or privacy of the data is added. If the 76 source host encrypts the data stream then the encapsulated packets 77 can be encrypted but would be redundant. However, when plaintext 78 packets are sent by hosts, this design can encrypt the user payload 79 to maintain privacy on the path between the encapsulator (the ITR or 80 PITR) to a decapsulator (ETR or RTR). 82 This draft has the following requirements for the solution space: 84 o Do not require a separate Public Key Infrastructure (PKI) that is 85 out of scope of the LISP control-plane architecture. 87 o The budget for key exchange MUST be one round-trip time. That is, 88 only a two packet exchange can occur. 90 o Use symmetric keying so faster cryptography can be performed in 91 the LISP data plane. 93 o Avoid a third-party trust anchor if possible. 95 o Provide for rekeying when secret keys are compromised. 97 o At this time, encapsulated packet authentication is not a strong 98 requirement. 100 2. Overview 102 The approach proposed in this draft is to not rely on the LISP 103 mapping system to store security keys. This will provide for a 104 simpler and more secure mechanism. Secret shared keys will be 105 negotiated between the ITR and the ETR in Map-Request and Map-Reply 106 messages. Therefore, when an ITR needs to obtain the RLOC of an ETR, 107 it will get security material to compute a shared secret with the 108 ETR. 110 The ITR can compute 3 shared-secrets per ETR the ITR is encapsulating 111 to. And when the ITR encrypts a packet before encapsulation, it will 112 identify the key it used for the crypto calculation so the ETR knows 113 which key to use for decrypting the packet after decapsulation. By 114 using key-ids in the LISP header, we can also get rekeying 115 functionality. 117 3. Diffie-Hellman Key Exchange 119 LISP will use a Diffie-Hellman [RFC2631] key exchange sequence and 120 computation for computing a shared secret. The Diffie-Hellman 121 parameters will be passed in Map-Request and Map-Reply messages. 123 Here is a brief description how Diff-Hellman works: 125 +----------------------------+---------+----------------------------+ 126 | ITR | | ETR | 127 +------+--------+------------+---------+------------+---------------+ 128 |Secret| Public | Calculates | Sends | Calculates | Public |Secret| 129 +------|--------|------------|---------|------------|--------|------+ 130 | i | p,g | | p,g --> | | | e | 131 +------|--------|------------|---------|------------|--------|------+ 132 | i | p,g,I |g^i mod p=I | I --> | | p,g,I | e | 133 +------|--------|------------|---------|------------|--------|------+ 134 | i | p,g,I | | <-- E |g^e mod p=E | p,g | e | 135 +------|--------|------------|---------|------------|--------|------+ 136 | i,s |p,g,I,E |E^i mod p=s | |I^e mod p=s |p,g,I,E | e,s | 137 +------|--------|------------|---------|------------|--------|------+ 139 Public-key exchange for computing a shared private key [DH] 141 Diffie-Hellman parameters 'p' and 'g' must be the same values used by 142 the ITR and ETR. The ITR computes public-key 'I' and transmits 'I' 143 in a Map-Request packet. When the ETR receives the Map-Request, it 144 uses parameters 'p' and 'g' to compute the ETR's public key 'E'. The 145 ETR transmits 'E' in a Map-Reply message. At this point, the ETR has 146 enough information to compute 's', the shared secret, by using 'I' as 147 the base and the ETR's private key 'e' as the exponent. When the ITR 148 receives the Map-Reply, it uses the ETR's public-key 'E' with the 149 ITR's private key 'i' to compute the same 's' shared secret the ETR 150 computed. The value 'p' is used as a modulus to create the width of 151 the shared secret 's'. 153 4. Encoding and Transmitting Key Material 155 The Diffie-Hellman key material is transmitted in Map-Request and 156 Map-Reply messages. Diffie-Hellman parameters are encoded in the 157 LISP Security Type LCAF [LCAF]. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | AFI = 16387 | Rsvd1 | Flags | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type = 11 | Rsvd2 | 6 + n | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Key Length | Key Material ... | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | ... Key Material | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | AFI = x | Locator Address ... | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Diffie-Hellman parameters encoded in Key Material field 177 The 'Key Count' field encodes the number of {'Key-Length', 'Key- 178 Material'} fields included in the encoded LCAF. A maximum number of 179 keys that can be encoded are 3 keys, each identified by key-id 1, 180 followed by key-id 2, an finally key-id 3. 182 The 'Key Algorithm' encodes the cryptographic algorithm used. The 183 following values are defined: 185 Null: 0 186 AES: 1 187 3DES: 2 188 SHA-256: 3 190 The 'Key Material' field is encoded as follows: 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | g-length | g-value ... | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | p-length | p-value ... | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Public Key ... | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Key Length describes the length of the Key Material field 202 When an ITR or PITR sends a Map-Request, they will encode their own 203 RLOC in Security Type LCAF format within the ITR-RLOCs field. When a 204 ETR or RTR sends a Map-Reply, they will encode their RLOCs in 205 Security Type LCAF format within the RLOC-record field of each EID- 206 record supplied. 208 If an ITR or PITR sends a Map-Request with a Security Type LCAF 209 included and the ETR or RTR does not want to have encapsulated 210 traffic encrypted, they will return a Map-Reply with no RLOC records 211 encoded with the Security Type LCAF. This signals to the ITR or PITR 212 that it should not encrypt traffic (it cannot encrypt traffic anyways 213 since no ETR public-key was returned). 215 5. Data-Plane Operation 217 The LISP encapsulation header [RFC6830] requires changes to encode 218 the key-id for the key being used for encryption. 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 / | Source Port = xxxx | Dest Port = 4341 | 222 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 \ | UDP Length | UDP Checksum | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 L |N|L|E|V|I|P|K|K| Nonce/Map-Version | 226 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 S / | Instance ID/Locator-Status-Bits | 228 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 K-bits indicate when packet is encrypted and which key used 232 When the KK bits are 00, the encapsulated packet is not encrypted. 233 When the value of the KK bits is 1, 2, or 3, it encodes the key-id of 234 the secret keys computed during the Diffie-Hellman Map-Request/ 235 Map-Reply exchange. 237 When an ITR or PITR receives a packet to be encapsulated, they will 238 first decide what key to use, encode the key-id into the LISP header, 239 and use that key to encrypt all packet data that follows the LISP 240 header. Therefore, the outer header, UDP header, and LISP header 241 travel as plaintext. 243 6. Dynamic Rekeying 245 Since multiple keys can be encoded in both control and data messages, 246 an ITR can encapsulate and encrypt with a specific key while it is 247 negotiating other keys with the same ETR. Soon as an ETR or RTR 248 returns a Map-Reply, it should be prepared to decapsulate and decrypt 249 using the new keys computed with the new Diffie-Hellman parameters 250 received in the Map-Request and returned in the Map-Reply. 252 RLOC-probing can be used to change keys by the ITR at any time. And 253 when an initial Map-Request is sent to populate the ITR's map-cache, 254 the Map-Requests flows across the mapping system where a single ETR 255 from the Map-Reply RLOC-set will respond. If the ITR decides to use 256 the other RLOCs in the RLOC-set, it MUST send a Map-Request directly 257 to key negotiate with the ETR. This process may be used to test 258 reachability from an ITR to an ETR initially when a map-cache entry 259 is added for the first time, so an ITR can get both reachability 260 status and keys negotiated with one Map-Request/Map-Reply exchange. 262 A rekeying event is defined to be when an ITR or PITR changes the p, 263 g, or the public-key in a Map-Request. The ETR or RTR compares the 264 p, g, and public-key it last received from the ITR for the key-id, 265 and if any value has changed, it computes a new public-key of its own 266 with the new p and g values from the Map-Request and returns it in 267 the Map-Reply. Now a new shared secret is computed and can be used 268 for the key-id for encryption by the ITR and decryption by the ETR. 269 When the ITR or PITR starts this process of negotiating a new key, it 270 must not use the corresponding key-id in encapsulated packets until 271 it receives a Map-Reply from the ETR with the p and g values it 272 expects (the values it sent in a Map-Request). 274 7. Future Work 276 By using AES-GCM [RFC5116], or HMAC-CBC [AES-CBC], it has been 277 suggested that encapsulated packet authentication (through encryption 278 [RFC4106]) could be supported. There is current work in progress to 279 investigate these techniques for the LISP data-plane. However, it 280 will require encapsulation header changes to LISP. 282 8. Security Considerations 284 The LISP working group will seek help from the SAAG working group for 285 security advice. The SAAG will be involved early in the design 286 process so they have early input and review. 288 9. IANA Considerations 290 This draft requires no considerations from IANA. 292 10. References 294 10.1. Normative References 296 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 297 RFC 2631, June 1999. 299 [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode 300 (GCM) in IPsec Encapsulating Security Payload (ESP)", 301 RFC 4106, June 2005. 303 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 304 Encryption", RFC 5116, January 2008. 306 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 307 Locator/ID Separation Protocol (LISP)", RFC 6830, 308 January 2013. 310 10.2. Informative References 312 [AES-CBC] McGrew, D., Foley, J., and K. Paterson, "Authenticated 313 Encryption with AES-CBC and HMAC-SHA", 314 draft-mcgrew-aead-aes-cbc-hmac-sha2-03.txt (work in 315 progress). 317 [DH] "Diffie-Hellman key exchange", Wikipedia http:// 318 en.wikipedia.org/wiki/Diffie-Hellman_key_exchange. 320 [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 321 Address Format", draft-ietf-lisp-lcaf-04.txt (work in 322 progress). 324 Appendix A. Acknowledgments 326 The author would like to thank Dan Harkins, Brian Weis, Joel Halpern, 327 Fabio Maino, Ed Lopez, and Roger Jorgensen for their interest, 328 suggestions, and discussions about LISP data-plane security. 330 In addition, the support and suggestions from the SAAG working group 331 were helpful and appreciative. 333 Appendix B. Document Change Log 335 B.1. Changes to draft-farinacci-lisp-crypto-00.txt 337 o Initial draft posted February 2014. 339 Author's Address 341 Dino Farinacci 342 lispers.net 343 San Jose, California 344 USA 346 Phone: 408-718-2001 347 Email: farinacci@gmail.com