idnits 2.17.1 draft-ietf-lisp-sec-12.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 (November 16, 2016) is 2717 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Maino 3 Internet-Draft V. Ermagan 4 Intended status: Experimental Cisco Systems 5 Expires: May 20, 2017 A. Cabellos 6 Technical University of Catalonia 7 D. Saucez 8 INRIA 9 November 16, 2016 11 LISP-Security (LISP-SEC) 12 draft-ietf-lisp-sec-12 14 Abstract 16 This memo specifies LISP-SEC, a set of security mechanisms that 17 provides origin authentication, integrity and anti-replay protection 18 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 19 process. LISP-SEC also enables verification of authorization on EID- 20 prefix claims in Map-Reply messages. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 20, 2017. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 64 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 65 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 5 66 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 67 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . 7 68 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 69 5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . 11 70 5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . 11 71 5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 13 72 5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 14 73 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14 74 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15 75 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15 76 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16 77 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 79 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17 80 6.2. Random Number Generation . . . . . . . . . . . . . . . . 17 81 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 82 6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 18 85 7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 18 86 7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19 87 7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 19 88 7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 90 9. Normative References . . . . . . . . . . . . . . . . . . . . 20 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 The Locator/ID Separation Protocol [RFC6830] is a network-layer-based 96 protocol that enables separation of IP addresses into two new 97 numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators 98 (RLOCs). EID-to-RLOC mappings are stored in a database, the LISP 99 Mapping System, and made available via the Map-Request/Map-Reply 100 lookup process. If these EID-to-RLOC mappings, carried through Map- 101 Reply messages, are transmitted without integrity protection, an 102 adversary can manipulate them and hijack the communication, 103 impersonate the requested EID, or mount Denial of Service or 104 Distributed Denial of Service attacks. Also, if the Map-Reply 105 message is transported unauthenticated, an adversarial LISP entity 106 can overclaim an EID-prefix and maliciously redirect traffic directed 107 to a large number of hosts. The LISP-SEC threat model, described in 108 Section 3, is built on top of the LISP threat model defined in 109 [RFC7835], that includes a detailed description of "overclaiming" 110 attack. 112 This memo specifies LISP-SEC, a set of security mechanisms that 113 provides origin authentication, integrity and anti-replay protection 114 to LISP's EID-to-RLOC mapping data conveyed via mapping lookup 115 process. LISP-SEC also enables verification of authorization on EID- 116 prefix claims in Map-Reply messages, ensuring that the sender of a 117 Map-Reply that provides the location for a given EID-prefix is 118 entitled to do so according to the EID prefix registered in the 119 associated Map-Server. Map-Register security, including the right 120 for a LISP entity to register an EID-prefix or to claim presence at 121 an RLOC, is out of the scope of LISP-SEC. Additional security 122 considerations are described in Section 6. 124 2. Definition of Terms 126 One-Time Key (OTK): An ephemeral randomly generated key that must 127 be used for a single Map-Request/Map-Reply exchange. 129 ITR One-Time Key (ITR-OTK): The One-Time Key generated at the ITR. 131 MS One-Time Key (MS-OTK): The One-Time Key generated at the Map- 132 Server. 134 Authentication Data (AD): Metadata that is included either in a 135 LISP Encapsulated Control Message (ECM) header, as defined in 136 Section 6.1.8 of [RFC6830], or in a Map-Reply message to support 137 confidentiality, integrity protection, and verification of EID- 138 prefix authorization. 140 OTK Authentication Data (OTK-AD): The portion of ECM 141 Authentication Data that contains a One-Time Key. 143 EID Authentication Data (EID-AD): The portion of ECM and Map-Reply 144 Authentication Data used for verification of EID-prefix 145 authorization. 147 Packet Authentication Data (PKT-AD): The portion of Map-Reply 148 Authentication Data used to protect the integrity of the Map-Reply 149 message. 151 For definitions of other terms, notably Map-Request, Map-Reply, 152 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server 153 (MS), and Map-Resolver (MR) please consult the LISP specification 154 [RFC6830]. 156 3. LISP-SEC Threat Model 158 LISP-SEC addresses the control plane threats, described in [RFC7835], 159 that target EID-to-RLOC mappings, including manipulations of Map- 160 Request and Map-Reply messages, and malicious ETR EID prefix 161 overclaiming. LISP-SEC makes two main assumptions: (1) the LISP 162 mapping system is expected to deliver a Map-Request message to their 163 intended destination ETR as identified by the EID, and (2) no man-in- 164 the-middle (MITM) attack can be mounted within the LISP Mapping 165 System. How the Mapping System is protected from MITM attacks 166 depends from the particular Mapping Systems used, and is out of the 167 scope of this memo. Furthermore, while LISP-SEC enables detection of 168 EID prefix overclaiming attacks, it assumes that Map-Servers can 169 verify the EID prefix authorization at time of registration. 171 According to the threat model described in [RFC7835] LISP-SEC assumes 172 that any kind of attack, including MITM attacks, can be mounted in 173 the access network, outside of the boundaries of the LISP mapping 174 system. An on-path attacker, outside of the LISP mapping system can, 175 for example, hijack Map-Request and Map-Reply messages, spoofing the 176 identity of a LISP node. Another example of on-path attack, called 177 overclaiming attack, can be mounted by a malicious Egress Tunnel 178 Router (ETR), by overclaiming the EID-prefixes for which it is 179 authoritative. In this way the ETR can maliciously redirect traffic 180 directed to a large number of hosts. 182 4. Protocol Operations 184 The goal of the security mechanisms defined in [RFC6830] is to 185 prevent unauthorized insertion of mapping data by providing origin 186 authentication and integrity protection for the Map-Registration, and 187 by using the nonce to detect unsolicited Map-Reply sent by off-path 188 attackers. 190 LISP-SEC builds on top of the security mechanisms defined in 191 [RFC6830] to address the threats described in Section 3 by leveraging 192 the trust relationships existing among the LISP entities 193 participating to the exchange of the Map-Request/Map-Reply messages. 194 Those trust relationships are used to securely distribute a One-Time 195 Key (OTK) that provides origin authentication, integrity and anti- 196 replay protection to mapping data conveyed via the mapping lookup 197 process, and that effectively prevent overclaiming attacks. The 198 processing of security parameters during the Map-Request/Map-Reply 199 exchange is as follows: 201 o The ITR-OTK is generated and stored at the ITR, and securely 202 transported to the Map-Server. 204 o The Map-Server uses the ITR-OTK to compute a Keyed-Hashing for 205 Message Authentication (HMAC) [RFC2104] that protects the 206 integrity of the mapping data known to the Map-Server to prevent 207 overclaiming attacks. The Map-Server also derives a new OTK, the 208 MS-OTK, that is passed to the ETR, by applying a Key Derivation 209 Function (KDF) to the ITR-OTK. 211 o The ETR uses the MS-OTK to compute an HMAC that protects the 212 integrity of the Map-Reply sent to the ITR. 214 o Finally, the ITR uses the stored ITR-OTK to verify the integrity 215 of the mapping data provided by both the Map-Server and the ETR, 216 and to verify that no overclaiming attacks were mounted along the 217 path between the Map-Server and the ITR. 219 Section 5 provides the detailed description of the LISP-SEC control 220 messages and their processing, while the rest of this section 221 describes the flow of protocol operations at each entity involved in 222 the Map-Request/Map-Reply exchange: 224 o The ITR, upon needing to transmit a Map-Request message, generates 225 and stores an OTK (ITR-OTK). This ITR-OTK is included into the 226 Encapsulated Control Message (ECM) that contains the Map-Request 227 sent to the Map-Resolver. To provide confidentiality to the ITR- 228 OTK over the path between the ITR and its Map-Resolver, the ITR- 229 OTK SHOULD be encrypted using a preconfigured key shared between 230 the ITR and the Map-Resolver, similar to the key shared between 231 the ETR and the Map-Server in order to secure ETR registration 232 [RFC6833]. 234 o The Map-Resolver decapsulates the ECM message, decrypts the ITR- 235 OTK, if needed, and forwards through the Mapping System the 236 received Map-Request and the ITR-OTK, as part of a new ECM 237 message. As described in Section 5.6, the LISP Mapping System 238 delivers the ECM to the appropriate Map-Server, as identified by 239 the EID destination address of the Map-Request. 241 o The Map-Server is configured with the location mappings and policy 242 information for the ETR responsible for the EID destination 243 address. Using this preconfigured information, the Map-Server, 244 after the decapsulation of the ECM message, finds the longest 245 match EID-prefix that covers the requested EID in the received 246 Map-Request. The Map-Server adds this EID-prefix, together with 247 an HMAC computed using the ITR-OTK, to a new Encapsulated Control 248 Message that contains the received Map-Request. 250 o The Map-Server derives a new OTK, the MS-OTK, by applying a Key 251 Derivation Function (KDF) to the ITR-OTK. This MS-OTK is included 252 in the Encapsulated Control Message that the Map-Server uses to 253 forward the Map-Request to the ETR. To provide MS-OTK 254 confidentiality over the path between the Map-Server and the ETR, 255 the MS-OTK SHOULD be encrypted using the key shared between the 256 ETR and the Map-Server in order to secure ETR registration 257 [RFC6833]. 259 o If the Map-Server is acting in proxy mode, as specified in 260 [RFC6830], the ETR is not involved in the generation of the Map- 261 Reply. In this case the Map-Server generates the Map-Reply on 262 behalf of the ETR as described below. 264 o The ETR, upon receiving the ECM encapsulated Map-Request from the 265 Map-Server, decrypts the MS-OTK, if needed, and originates a 266 standard Map-Reply that contains the EID-to-RLOC mapping 267 information as specified in [RFC6830]. 269 o The ETR computes an HMAC over this standard Map-Reply, keyed with 270 MS-OTK to protect the integrity of the whole Map-Reply. The ETR 271 also copies the EID-prefix authorization data that the Map-Server 272 included in the ECM encapsulated Map-Request into the Map-Reply 273 message. The ETR then sends this complete Map-Reply message to 274 the requesting ITR. 276 o The ITR, upon receiving the Map-Reply, uses the locally stored 277 ITR-OTK to verify the integrity of the EID-prefix authorization 278 data included in the Map-Reply by the Map-Server. The ITR 279 computes the MS-OTK by applying the same KDF used by the Map- 280 Server, and verifies the integrity of the Map-Reply. If the 281 integrity checks fail, the Map-Reply MUST be discarded. Also, if 282 the EID-prefixes claimed by the ETR in the Map-Reply are not equal 283 or more specific than the EID-prefix authorization data inserted 284 by the Map-Server, the ITR MUST discard the Map-Reply. 286 5. LISP-SEC Control Messages Details 288 LISP-SEC metadata associated with a Map-Request is transported within 289 the Encapsulated Control Message that contains the Map-Request. 291 LISP-SEC metadata associated with the Map-Reply is transported within 292 the Map-Reply itself. 294 5.1. Encapsulated Control Message LISP-SEC Extensions 296 LISP-SEC uses the ECM (Encapsulated Control Message) defined in 297 [RFC6830] with Type set to 8, and S bit set to 1 to indicate that the 298 LISP header includes Authentication Data (AD). The format of the 299 LISP-SEC ECM Authentication Data is defined in the following figure. 300 OTK-AD stands for One-Time Key Authentication Data and EID-AD stands 301 for EID Authentication Data. 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | ECM AD Type |V| Reserved | Requested HMAC ID | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 308 | OTK Length | OTK Encryption ID | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 310 | One-Time-Key Preamble ... | | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD 312 | ... One-Time-Key Preamble | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 314 ~ One-Time Key (128 bits) ~/ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 316 | EID-AD Length | KDF ID | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 318 | Record Count | Reserved | EID HMAC ID |EID-AD 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 320 | Reserved | EID mask-len | EID-AFI | | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 322 ~ EID-prefix ... ~ | | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 324 ~ EID HMAC ~ | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 327 LISP-SEC ECM Authentication Data 329 ECM AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 331 V: Key Version bit. This bit is toggled when the sender switches 332 to a new OTK wrapping key 334 Reserved: Set to 0 on transmission and ignored on receipt. 336 Requested HMAC ID: The HMAC algorithm requested by the ITR. See 337 Section 5.4 for details. 339 OTK Length: The length (in bytes) of the OTK Authentication Data 340 (OTK-AD), that contains the OTK Preamble and the OTK. 342 OTK Encryption ID: The identifier of the key wrapping algorithm 343 used to encrypt the One-Time-Key. When a 128-bit OTK is sent 344 unencrypted by the Map-Resolver, the OTK Encryption ID is set to 345 NULL_KEY_WRAP_128. See Section 5.5 for more details. 347 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 348 the OTK is encrypted, this field MAY carry additional metadata 349 resulting from the key wrapping operation. When a 128-bit OTK is 350 sent unencrypted by Map-Resolver, the OTK Preamble is set to 351 0x0000000000000000 (64 bits). See Section 5.5 for details. 353 One-Time-Key: the OTK encrypted (or not) as specified by OTK 354 Encryption ID. See Section 5.5 for details. 356 EID-AD Length: length (in bytes) of the EID Authentication Data 357 (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only 358 fills the KDF ID field, and all the remaining fields part of the 359 EID-AD are not present. An EID-AD MAY contain multiple EID- 360 records. Each EID-record is 4-byte long plus the length of the 361 AFI-encoded EID-prefix. 363 KDF ID: Identifier of the Key Derivation Function used to derive 364 the MS-OTK. The ITR MAY use this field to indicate the 365 recommended KDF algorithm, according to local policy. The Map- 366 Server can overwrite the KDF ID if it does not support the KDF ID 367 recommended by the ITR. See Section 5.4 for more details. 369 Record Count: The number of records in this Map-Request message. 370 A record is comprised of the portion of the packet that is labeled 371 'Rec' above and occurs the number of times equal to Record Count. 373 Reserved: Set to 0 on transmission and ignored on receipt. 375 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 376 integrity of the EID-AD. This field is filled by Map-Server that 377 computed the EID-prefix HMAC. See Section 5.4 for more details. 379 EID mask-len: Mask length for EID-prefix. 381 EID-AFI: Address family of EID-prefix according to [RFC5226] 383 EID-prefix: The Map-Server uses this field to specify the EID- 384 prefix that the destination ETR is authoritative for, and is the 385 longest match for the requested EID. 387 EID HMAC: HMAC of the EID-AD computed and inserted by Map-Server. 388 Before computing the HMAC operation the EID HMAC field MUST be set 389 to 0. The HMAC covers the entire EID-AD. 391 5.2. Map-Reply LISP-SEC Extensions 393 LISP-SEC uses the Map-Reply defined in [RFC6830], with Type set to 2, 394 and S bit set to 1 to indicate that the Map-Reply message includes 395 Authentication Data (AD). The format of the LISP-SEC Map-Reply 396 Authentication Data is defined in the following figure. PKT-AD is 397 the Packet Authentication Data that covers the Map-Reply payload. 399 0 1 2 3 400 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 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | MR AD Type | Reserved | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 404 | EID-AD Length | KDF ID | | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 406 | Record Count | Reserved | EID HMAC ID |EID-AD 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ | 408 | Reserved | EID mask-len | EID-AFI | | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec | 410 ~ EID-prefix ... ~ | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ | 412 ~ EID HMAC ~ | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 414 | PKT-AD Length | PKT HMAC ID |\ 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 416 ~ PKT HMAC ~PKT-AD 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 419 LISP-SEC Map-Reply Authentication Data 421 MR AD Type: 1 (LISP-SEC Authentication Data). See Section 7. 423 EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY 424 contain multiple EID-records. Each EID-record is 4-byte long plus 425 the length of the AFI-encoded EID-prefix. 427 KDF ID: Identifier of the Key Derivation Function used to derive 428 MS-OTK. See Section 5.7 for more details. 430 Record Count: The number of records in this Map-Reply message. A 431 record is comprised of the portion of the packet that is labeled 432 'Rec' above and occurs the number of times equal to Record Count. 434 Reserved: Set to 0 on transmission and ignored on receipt. 436 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 437 integrity of the EID-AD. See Section 5.7 for more details. 439 EID mask-len: Mask length for EID-prefix. 441 EID-AFI: Address family of EID-prefix according to [RFC5226]. 443 EID-prefix: This field contains an EID-prefix that the destination 444 ETR is authoritative for, and is the longest match for the 445 requested EID. 447 EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. 448 Before computing the HMAC operation the EID HMAC field MUST be set 449 to 0. The HMAC covers the entire EID-AD. 451 PKT-AD Length: length (in bytes) of the Packet Authentication Data 452 (PKT-AD). 454 PKT HMAC ID: Identifier of the HMAC algorithm used to protect the 455 integrity of the Map-reply. 457 PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- 458 SEC Authentication Data. The scope of the authentication goes 459 from the Map-Reply Type field to the PKT HMAC field included. 460 Before computing the HMAC operation the PKT HMAC field MUST be set 461 to 0. See Section 5.8 for more details. 463 5.3. Map-Register LISP-SEC Extentions 465 This memo is allocating one of the bits marked as Reserved in the 466 Map-Register message defined in Section 6.1.6 of [RFC6830]. More 467 precisely, the second bit after the Type field in a Map-Register 468 message is allocated as the S bit. The S bit indicates to the Map- 469 Server that the registering ETR is LISP-SEC enabled. An ETR that 470 supports LISP-SEC MUST set the S bit in its Map-Register messages. 472 5.4. ITR Processing 474 Upon creating a Map-Request, the ITR generates a random ITR-OTK that 475 is stored locally, together with the nonce generated as specified in 476 [RFC6830]. 478 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 479 1, to indicate the presence of Authentication Data. If the ITR and 480 the Map-Resolver are configured with a shared key, the ITR-OTK 481 confidentiality SHOULD be protected by wrapping the ITR-OTK with the 482 algorithm specified by the OTK Encryption ID field. See Section 5.5 483 for further details on OTK encryption. 485 The Requested HMAC ID field contains the suggested HMAC algorithm to 486 be used by the Map-Server and the ETR to protect the integrity of the 487 ECM Authentication data and of the Map-Reply. 489 The KDF ID field specifies the suggested key derivation function to 490 be used by the Map-Server to derive the MS-OTK. A KDF Value of NONE 491 (0), MAY be used to specify that the ITR has no preferred KDF ID. 493 The EID-AD length is set to 4 bytes, since the Authentication Data 494 does not contain EID-prefix Authentication Data, and the EID-AD 495 contains only the KDF ID field. 497 In response to an encapsulated Map-Request that has the S-bit set, an 498 ITR MUST receive a Map-Reply with the S-bit set, that includes an 499 EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the 500 ITR MUST discard it. In response to an encapsulated Map-Request with 501 S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and 502 the ITR SHOULD discard the Map-Reply if the S-bit is set. 504 Upon receiving a Map-Reply, the ITR must verify the integrity of both 505 the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of 506 the integrity checks fails. 508 The integrity of the EID-AD is verified using the locally stored ITR- 509 OTK to re-compute the HMAC of the EID-AD using the algorithm 510 specified in the EID HMAC ID field. If the EID HMAC ID field does 511 not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply 512 and send, at the first opportunity it needs to, a new Map-Request 513 with a different Requested HMAC ID field, according to ITR's local 514 policy. The scope of the HMAC operation covers the entire EID-AD, 515 from the EID-AD Length field to the EID HMAC field, which must be set 516 to 0 before the computation of the HMAC. 518 ITR MUST set the EID HMAC ID field to 0 before computing the HMAC. 520 To verify the integrity of the PKT-AD, first the MS-OTK is derived 521 from the locally stored ITR-OTK using the algorithm specified in the 522 KDF ID field. This is because the PKT-AD is generated by the ETR 523 using the MS-OTK. If the KDF ID in the Map-Reply does not match the 524 KDF ID requested in the Map-Request, the ITR SHOULD discard the Map- 525 Reply and send, at the first opportunity it needs to, a new Map- 526 Request with a different KDF ID, according to ITR's local policy. 528 The derived MS-OTK is then used to re-compute the HMAC of the PKT-AD 529 using the Algorithm specified in the PKT HMAC ID field. If the PKT 530 HMAC ID field does not match the Requested HMAC ID the ITR SHOULD 531 discard the Map-Reply and send, at the first opportunity it needs to, 532 a new Map-Request with a different Requested HMAC ID according to 533 ITR's local policy or until all HMAC IDs supported by the ITR have 534 been attempted. 536 Each individual Map-Reply EID-record is considered valid only if: (1) 537 both EID-AD and PKT-AD are valid, and (2) the intersection of the 538 EID-prefix in the Map-Reply EID-record with one of the EID-prefixes 539 contained in the EID-AD is not empty. After identifying the Map- 540 Reply record as valid, the ITR sets the EID-prefix in the Map-Reply 541 record to the value of the intersection set computed before, and adds 542 the Map-Reply EID-record to its EID-to-RLOC cache, as described in 543 [RFC6830]. An example of Map-Reply record validation is provided in 544 Section 5.4.1. 546 The ITR SHOULD send SMR triggered Map-Requests over the mapping 547 system in order to receive a secure Map-Reply. If an ITR accepts 548 piggybacked Map-Replies, it SHOULD also send a Map-Request over the 549 mapping system in order to verify the piggybacked Map-Reply with a 550 secure Map-Reply. 552 5.4.1. Map-Reply Record Validation 554 The payload of a Map-Reply may contain multiple EID-records. The 555 whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide 556 integrity protection and origin authentication to the EID-prefix 557 records claimed by the ETR. The Authentication Data field of a Map- 558 Reply may contain multiple EID-records in the EID-AD. The EID-AD is 559 signed by the Map-Server, with the EID HMAC, to provide integrity 560 protection and origin authentication to the EID-prefix records 561 inserted by the Map-Server. 563 Upon receiving a Map-Reply with the S-bit set, the ITR first checks 564 the validity of both the EID HMAC and of the PKT-AD HMAC. If either 565 one of the HMACs is not valid, a log action MUST be taken and the 566 Map-Reply MUST NOT be processed any further. If both HMACs are 567 valid, the ITR proceeds with validating each individual EID-record 568 claimed by the ETR by computing the intersection of each one of the 569 EID-prefix contained in the payload of the Map-Reply with each one of 570 the EID-prefixes contained in the EID-AD. An EID-record is valid 571 only if at least one of the intersections is not the empty set. 573 For instance, the Map-Reply payload contains 3 mapping record EID- 574 prefixes: 576 2001:db8:0102::/48 578 2001:db8:0103::/48 580 2001:db8:0200::/40 582 The EID-AD contains two EID-prefixes: 584 2001:db8:0103::/48 586 2001:db8:0203::/48 588 The EID-record with EID-prefix 2001:db8:0102::/48 is not eligible to 589 be used by the ITR since it is not included in any of the EID-ADs 590 signed by the Map-Server. A log action MUST be taken. 592 The EID-record with EID-prefix 2001:db8:0103::/48 is eligible to be 593 used by the ITR because it matches the second EID-prefix contained in 594 the EID-AD. 596 The EID-record with EID-prefix 2001:db8:0200::/40 is not eligible to 597 be used by the ITR since it is not included in any of the EID-ADs 598 signed by the Map-Server. A log action MUST be taken. In this last 599 example the ETR is trying to over claim the EID-prefix 600 2001:db8:0200::/40, but the Map-Server authorized only 601 2001:db8:0203::/48, hence the EID-record is discarded. 603 5.4.2. PITR Processing 605 The processing performed by a PITR is equivalent to the processing of 606 an ITR. However, if the PITR is directly connected to a Mapping 607 System such as LISP+ALT [RFC6836], the PITR performs the functions of 608 both the ITR and the Map-Resolver forwarding the Map-Request 609 encapsulated in an ECM header that includes the Authentication Data 610 fields as described in Section 5.6. 612 5.5. Encrypting and Decrypting an OTK 614 MS-OTK confidentiality is required in the path between the Map-Server 615 and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured 616 key shared between the Map-Server and the ETR for the purpose of 617 securing ETR registration [RFC6833]. Similarly, if ITR-OTK 618 confidentiality is required in the path between the ITR and the Map- 619 Resolver, the ITR-OTK SHOULD be encrypted with a key shared between 620 the ITR and the Map-Resolver. 622 The OTK is encrypted using the algorithm specified in the OTK 623 Encryption ID field. When the AES Key Wrap algorithm is used to 624 encrypt a 128-bit OTK, according to [RFC3394], the AES Key Wrap 625 Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). 626 The output of the AES Key Wrap operation is 192-bit long. The most 627 significant 64-bit are copied in the One-Time Key Preamble field, 628 while the 128 less significant bits are copied in the One-Time Key 629 field of the LISP-SEC Authentication Data. 631 When decrypting an encrypted OTK the receiver MUST verify that the 632 Initialization Value resulting from the AES Key Wrap decryption 633 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 634 the receiver MUST discard the entire message. 636 When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set 637 to NULL_KEY_WRAP_128, and the OTK Preamble is set to 638 0x0000000000000000 (64 bits). 640 5.6. Map-Resolver Processing 642 Upon receiving an encapsulated Map-Request with the S-bit set, the 643 Map-Resolver decapsulates the ECM message. The ITR-OTK, if 644 encrypted, is decrypted as specified in Section 5.5. 646 Protecting the confidentiality of the ITR-OTK and, in general, the 647 security of how the Map-Request is handed by the Map-Resolver to the 648 Map-Server, is specific to the particular Mapping System used, and 649 outside of the scope of this memo. 651 In Mapping Systems where the Map-Server is compliant with [RFC6833], 652 the Map-Resolver originates a new ECM header with the S-bit set, that 653 contains the unencrypted ITR-OTK, as specified in Section 5.5, and 654 the other data derived from the ECM Authentication Data of the 655 received encapsulated Map-Request. 657 The Map-Resolver then forwards to the Map-Server the received Map- 658 Request, encapsulated in the new ECM header that includes the newly 659 computed Authentication Data fields. 661 5.7. Map-Server Processing 663 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 664 the Map-Server process the Map-Request according to the value of the 665 S-bit contained in the Map-Register sent by the ETR during 666 registration. 668 If the S-bit contained in the Map-Register was clear the Map-Server 669 decapsulates the ECM and generates a new ECM encapsulated Map-Request 670 that does not contain an ECM Authentication Data, as specified in 671 [RFC6830]. The Map-Server does not perform any further LISP-SEC 672 processing, and the Map-Reply will not be protected. 674 If the S-bit contained in the Map-Register was set the Map-Server 675 decapsulates the ECM and generates a new ECM Authentication Data. 676 The Authentication Data includes the OTK-AD and the EID-AD, that 677 contains EID-prefix authorization information, that are ultimately 678 sent to the requesting ITR. 680 The Map-Server updates the OTK-AD by deriving a new OTK (MS-OTK) from 681 the ITR-OTK received with the Map-Request. MS-OTK is derived 682 applying the key derivation function specified in the KDF ID field. 683 If the algorithm specified in the KDF ID field is not supported, the 684 Map-Server uses a different algorithm to derive the key and updates 685 the KDF ID field accordingly. 687 The Map-Server and the ETR MUST be configured with a shared key for 688 mapping registration according to [RFC6833]. If MS-OTK 689 confidentiality is required, then the MS-OTK SHOULD be encrypted, by 690 wrapping the MS-OTK with the algorithm specified by the OTK 691 Encryption ID field as specified in Section 5.5. 693 The Map-Server includes in the EID-AD the longest match registered 694 EID-prefix for the destination EID, and an HMAC of this EID-prefix. 695 The HMAC is keyed with the ITR-OTK contained in the received ECM 696 Authentication Data, and the HMAC algorithm is chosen according to 697 the Requested HMAC ID field. If The Map-Server does not support this 698 algorithm, the Map-Server uses a different algorithm and specifies it 699 in the EID HMAC ID field. The scope of the HMAC operation covers the 700 entire EID-AD, from the EID-AD Length field to the EID HMAC field, 701 which must be set to 0 before the computation. 703 The Map-Server then forwards the updated ECM encapsulated Map- 704 Request, that contains the OTK-AD, the EID-AD, and the received Map- 705 Request to an authoritative ETR as specified in [RFC6830]. 707 5.7.1. Map-Server Processing in Proxy mode 709 If the Map-Server is in proxy mode, it generates a Map-Reply, as 710 specified in [RFC6830], with the S-bit set to 1. The Map-Reply 711 includes the Authentication Data that contains the EID-AD, computed 712 as specified in Section 5.7, as well as the PKT-AD computed as 713 specified in Section 5.8. 715 5.8. ETR Processing 717 Upon receiving an ECM encapsulated Map-Request with the S-bit set, 718 the ETR decapsulates the ECM message. The OTK field, if encrypted, 719 is decrypted as specified in Section 5.5 to obtain the unencrypted 720 MS-OTK. 722 The ETR then generates a Map-Reply as specified in [RFC6830] and 723 includes the Authentication Data that contains the EID-AD, as 724 received in the encapsulated Map-Request, as well as the PKT-AD. 726 The EID-AD is copied from the Authentication Data of the received 727 encapsulated Map-Request. 729 The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed 730 with the MS-OTK and computed using the HMAC algorithm specified in 731 the Requested HMAC ID field of the received encapsulated Map-Request. 733 If the ETR does not support the Requested HMAC ID, it uses a 734 different algorithm and updates the PKT HMAC ID field accordingly. 735 The scope of the HMAC operation covers the entire PKT-AD, from the 736 Map-Reply Type field to the PKT HMAC field, which must be set to 0 737 before the computation. 739 Finally the ETR sends the Map-Reply to the requesting ITR as 740 specified in [RFC6830]. 742 6. Security Considerations 744 6.1. Mapping System Security 746 The LISP-SEC threat model described in Section 3, assumes that the 747 LISP Mapping System is working properly and eventually delivers Map- 748 Request messages to a Map-Server that is authoritative for the 749 requested EID. 751 It is assumed that the Mapping System ensures the confidentiality of 752 the OTK, and the integrity of the Map-Reply data. However, how the 753 LISP Mapping System is secured is out of the scope of this document. 755 Similarly, Map-Register security, including the right for a LISP 756 entity to register an EID-prefix or to claim presence at an RLOC, is 757 out of the scope of LISP-SEC. 759 6.2. Random Number Generation 761 The ITR-OTK MUST be generated by a properly seeded pseudo-random (or 762 strong random) source. See [RFC4086] for advice on generating 763 security-sensitive random data 765 6.3. Map-Server and ETR Colocation 767 If the Map-Server and the ETR are colocated, LISP-SEC does not 768 provide protection from overclaiming attacks mounted by the ETR. 769 However, in this particular case, since the ETR is within the trust 770 boundaries of the Map-Server, ETR's overclaiming attacks are not 771 included in the threat model. 773 6.4. Deploying LISP-SEC 775 This memo is written according to [RFC2119]. Specifically, the use 776 of the key word SHOULD "or the adjective 'RECOMMENDED', mean that 777 there may exist valid reasons in particular circumstances to ignore a 778 particular item, but the full implications must be understood and 779 carefully weighed before choosing a different course". 781 Those deploying LISP-SEC according to this memo, should carefully 782 weight how the LISP-SEC threat model applies to their particular use 783 case or deployment. If they decide to ignore a particular 784 recommendation, they should make sure the risk associated with the 785 corresponding threats is well understood. 787 As an example, in certain closed and controlled deployments, it is 788 possible that the threat associated with a MiTM between the xTR and 789 the Mapping System is very low, and after carfeul consideration it 790 may be decided to allow a NULL key wrapping algorithm while carrying 791 the OTKs between the xTR and the Mapping System. 793 As an example at the other end of the spectrum, in certain other 794 deployments, attackers may be very sophisticated, and force the 795 deployers to enforce very strict policies in term of HMAC algorithms 796 accepted by an ITR. 798 Similar considerations apply to the entire LISP-SEC threat model, and 799 should guide the deployers and implementors whenever they encounter 800 the key word SHOULD across this memo. 802 7. IANA Considerations 804 7.1. ECM AD Type Registry 806 IANA is requested to create the "ECM Authentication Data Type" 807 registry with values 0-255, for use in the ECM LISP-SEC Extensions 808 Section 5.1. The registry MUST be initially populated with the 809 following values: 811 Name Value Defined In 812 ------------------------------------------------- 813 Reserved 0 This memo 814 LISP-SEC-ECM-EXT 1 This memo 816 HMAC Functions 818 Values 2-255 are unassigned. They are to be assigned according to 819 the "Specification Required" policy defined in [RFC5226]. 821 7.2. Map-Reply AD Type Registry 823 IANA is requested to create the "Map-Reply Authentication Data Type" 824 registry with values 0-255, for use in the Map-Reply LISP-SEC 825 Extensions Section 5.2. The registry MUST be initially populated 826 with the following values: 828 Name Value Defined In 829 ------------------------------------------------- 830 Reserved 0 This memo 831 LISP-SEC-MR-EXT 1 This memo 833 HMAC Functions 835 Values 2-255 are unassigned. They are to be assigned according to 836 the "Specification Required" policy defined in [RFC5226]. 838 7.3. HMAC Functions 840 IANA is requested to create the "LISP-SEC Authentication Data HMAC 841 ID" registry with values 0-65535 for use as Requested HMAC ID, EID 842 HMAC ID, and PKT HMAC ID in the LISP-SEC Authentication Data: 844 Name Number Defined In 845 ------------------------------------------------- 846 NONE 0 This memo 847 AUTH-HMAC-SHA-1-96 1 [RFC2104] 848 AUTH-HMAC-SHA-256-128 2 [RFC6234] 850 HMAC Functions 852 Values 3-65535 are unassigned. They are to be assigned according to 853 the "Specification Required" policy defined in [RFC5226]. 855 AUTH-HMAC-SHA-1-96 MUST be supported, AUTH-HMAC-SHA-256-128 SHOULD be 856 supported. 858 7.4. Key Wrap Functions 860 IANA is requested to create the "LISP-SEC Authentication Data Key 861 Wrap ID" registry with values 0-65535 for use as OTK key wrap 862 algorithms ID in the LISP-SEC Authentication Data: 864 Name Number Defined In 865 ------------------------------------------------- 866 Reserved 0 This memo 867 NULL-KEY-WRAP-128 1 This memo 868 AES-KEY-WRAP-128 2 [RFC3394] 870 Key Wrap Functions 872 Values 3-65535 are unassigned. They are to be assigned according to 873 the "Specification Required" policy defined in [RFC5226]. 875 NULL-KEY-WRAP-128, and AES-KEY-WRAP-128 MUST be supported. 877 NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 878 64-bit preamble set to 0x0000000000000000 (64 bits). 880 7.5. Key Derivation Functions 882 IANA is requested to create the "LISP-SEC Authentication Data Key 883 Derivation Function ID" registry with values 0-65535 for use as KDF 884 ID in the LISP-SEC Authentication Data: 886 Name Number Defined In 887 ------------------------------------------------- 888 NONE 0 This memo 889 HKDF-SHA1-128 1 [RFC5869] 891 Key Derivation Functions 893 Values 2-65535 are unassigned. They are to be assigned according to 894 the "Specification Required" policy defined in [RFC5226]. 896 HKDF-SHA1-128 MUST be supported 898 8. Acknowledgements 900 The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino 901 Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt 902 Noll for their valuable suggestions provided during the preparation 903 of this document. 905 9. Normative References 907 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 908 Hashing for Message Authentication", RFC 2104, 909 DOI 10.17487/RFC2104, February 1997, 910 . 912 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 913 Requirement Levels", BCP 14, RFC 2119, 914 DOI 10.17487/RFC2119, March 1997, 915 . 917 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 918 (AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394, 919 September 2002, . 921 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 922 "Randomness Requirements for Security", BCP 106, RFC 4086, 923 DOI 10.17487/RFC4086, June 2005, 924 . 926 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 927 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 928 DOI 10.17487/RFC5226, May 2008, 929 . 931 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 932 Key Derivation Function (HKDF)", RFC 5869, 933 DOI 10.17487/RFC5869, May 2010, 934 . 936 [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms 937 (SHA and SHA-based HMAC and HKDF)", RFC 6234, 938 DOI 10.17487/RFC6234, May 2011, 939 . 941 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 942 Locator/ID Separation Protocol (LISP)", RFC 6830, 943 DOI 10.17487/RFC6830, January 2013, 944 . 946 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 947 Protocol (LISP) Map-Server Interface", RFC 6833, 948 DOI 10.17487/RFC6833, January 2013, 949 . 951 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 952 "Locator/ID Separation Protocol Alternative Logical 953 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 954 January 2013, . 956 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 957 Separation Protocol (LISP) Threat Analysis", RFC 7835, 958 DOI 10.17487/RFC7835, April 2016, 959 . 961 Authors' Addresses 963 Fabio Maino 964 Cisco Systems 965 170 Tasman Drive 966 San Jose, California 95134 967 USA 969 Email: fmaino@cisco.com 971 Vina Ermagan 972 Cisco Systems 973 170 Tasman Drive 974 San Jose, California 95134 975 USA 977 Email: vermagan@cisco.com 979 Albert Cabellos 980 Technical University of Catalonia 981 c/ Jordi Girona s/n 982 Barcelona 08034 983 Spain 985 Email: acabello@ac.upc.edu 987 Damien Saucez 988 INRIA 989 2004 route des Lucioles - BP 93 990 Sophia Antipolis 991 France 993 Email: damien.saucez@inria.fr