idnits 2.17.1 draft-maino-lisp-sec-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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2011) is 4801 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC3339' is mentioned on line 499, but not defined == Missing Reference: 'RFC4634' is mentioned on line 642, but not defined ** Obsolete undefined reference: RFC 4634 (Obsoleted by RFC 6234) == Unused Reference: 'I-D.ietf-lisp-interworking' is defined on line 701, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lisp-10 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-01 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-06 == Outdated reference: A later version (-03) exists of draft-saucez-lisp-security-02 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 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: September 5, 2011 A. Cabellos 6 Technical University of Catalonia 7 D. Saucez 8 O. Bonaventure 9 Universite catholique de Louvain 10 March 4, 2011 12 LISP-Security (LISP-SEC) 13 draft-maino-lisp-sec-00.txt 15 Abstract 17 This memo specifies LISP-SEC, a set of security mechanisms that 18 provide origin authentication, integrity and anti-replay protection 19 to LISP's EID-to-RLOC mapping data. LISP-SEC also enables 20 verification of authorization on EID prefix claims. 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 September 5, 2011. 45 Copyright Notice 47 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . 3 65 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4 66 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 6 67 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 6 68 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 8 69 5.3. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10 70 5.4. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 11 71 5.5. Map-Resolver Processing . . . . . . . . . . . . . . . . . 12 72 5.6. Map-Server Processing . . . . . . . . . . . . . . . . . . 12 73 5.6.1. Map-Server Processing in Proxy mode . . . . . . . . . 13 74 5.7. ETR Processing . . . . . . . . . . . . . . . . . . . . . . 13 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 13 77 6.2. Random Number Generation . . . . . . . . . . . . . . . . . 14 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . . 14 80 7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . . 15 81 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . . 15 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 9. Normative References . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 The Locator/ID Separation Protocol [I-D.ietf-lisp] defines a set of 89 functions for routers to exchange information used to map from non- 90 routable Endpoint Identifiers (EIDs) to routable Routing Locators 91 (RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply 92 messages, are transmitted without integrity protection, an adversary 93 can manipulate them and hijack the communication, impersonate the 94 requested EID or mount Denial of Service or Distributed Denial of 95 Service attacks. Also, if the Map-Reply message is transported 96 unauthenticated, an adversarial LISP entity can overclaim an EID- 97 prefix and maliciously redirect traffic directed to a large number of 98 hosts. A detailed description of "overclaiming" attack is provided 99 in [I-D.saucez-lisp-security]. 101 This memo specifies LISP-SEC, a set of sceurity mechanisms that 102 provide origin authentication, integrity and anti-replay protection 103 to LISP's EID-to-RLOC mapping data. LISP-SEC also enables 104 verification of authorization on EID prefix claims, ensuring that the 105 entity that provides the location for a given EID prefix is entitled 106 to do so. 108 2. Definition of Terms 110 One-Time Key (OTK): An ephemeral randomly generated key that must 111 be used for a single Map-Request/Map-Reply exchange. 113 Encapsulated Control Message (ECM): A LISP control message that is 114 prepended with an additional LISP header. ECM is used by ITRs to 115 send LISP control messages to a Map-Resolver, by Map-Resolvers to 116 forward LISP control messages to a Map-Server, and by Map- 117 Resolvers to forward LISP control messages to an ETR. 119 Authentication Data (AD): Metadata that is included either in a 120 LISP ECM header or in a Map-Reply message to support 121 confidentiality, integrity protection, and verification of EID 122 prefix authorization. 124 For definitions of other terms, notably Map-Request, Map-Reply, 125 Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server 126 (MS) and Map-Resolver (MR) please consult the LISP specification 127 [I-D.ietf-lisp]. 129 3. LISP-SEC Threat Model 131 LISP-SEC addresses the control plane threats, described in 133 [I-D.saucez-lisp-security], that target EID-to-RLOC mappings, 134 including manipulations of Map-Request and Map-Reply messages, and 135 malicious xTR EID overclaiming. However LISP-SEC makes two main 136 assumptions that are not part of [I-D.saucez-lisp-security]. First, 137 the LISP Mapping System is expected to deliver Map-Request messages 138 to their intended destinations as identified by the EID. Second, no 139 Man-in-the-Middle (MiM) attack can be mounted within the LISP Mapping 140 System. 142 Accordingly to the threat model described in 143 [I-D.saucez-lisp-security] LISP-SEC assumes that any kind of attack, 144 including MiM attacks, can be mounted in the access network, outside 145 of the boundaries of the LISP mapping system. An on-path attacker, 146 outside of the LISP mapping service system can, for instance, hijack 147 mapping requests and replies, spoofing the identity of a LISP node. 148 Another example of on-path attack, called over claiming attack, can 149 be mounted by a malicious Egress Tunnel Router (ETR), by over 150 claiming the EID prefixes for which it is authoritative. In this way 151 the ETR can maliciously redirect traffic directed to a large number 152 of hosts. 154 4. Protocol Operations 156 The goal of the security mechanisms defined in [I-D.ietf-lisp] is to 157 prevent unauthorized insertion of mapping data, by providing origin 158 authentication and integrity protection for the Map-Registration, and 159 by using the nonce to detect unsolicited Map-Reply sent by off-path 160 attackers. 162 LISP-SEC builds on top of the security mechanisms defined in 163 [I-D.ietf-lisp] to address the threats described in Section 3 by 164 leveraging the trust relationships existing among the LISP entities 165 participating to the exchange of the Map-Request/Map-Reply messages. 166 Those trust relationships are used to securely distribute a One-Time 167 Key (OTK) that provides origin authentication, integrity and anti- 168 replay protection to mapping protocol data, and that effectively 169 prevent over claiming attacks. The processing of security parameters 170 during the Map-Request/Map-Reply exchange is as follows: 172 o The OTK is generated and stored at the ITR, and securely 173 transported to the Map-Server. 175 o The Map-Server uses the OTK to compute an HMAC that protects the 176 integrity of the mapping data provided by the Map-Server to 177 prevent overclaiming attacks. The Map-Server also derives a new 178 OTK (OTK-ETR), by applying a Key Derivation Function (KDF) to the 179 original OTK, that is passed to the ETR. 181 o The ETR uses the new OTK to compute an HMAC that protects the 182 integrity of the Map-Reply sent to the ITR. 184 o Finally, the ITR uses the stored OTK to verify the integrity of 185 the mapping data provided by both the Map-Server and the ETR, and 186 to verify that no overclaiming attacks were mounted along the path 187 between the Map-Server and the ITR. 189 Section 5 provides the detailed description of the LISP-SEC control 190 messages and their processing, while the rest of this section 191 describes the flow of protocol operations at each entity involved in 192 the Map-Request/Map-Reply exchange: 194 o The ITR, upon transmitting a Map-Request message, generates and 195 stores an OTK. This key is included into the Encapsulated Control 196 Message (ECM) that contains the Map-Request sent to the Map- 197 Resolver. To provide OTK confidentiality over the path between 198 the ITR and its Map-Resolver, the OTK SHOULD be encrypted using a 199 preconfigured key shared between the ITR and the Map-Resolver, 200 similar to the key shared between the ETR and the Map-Server in 201 order to secure ETR registration [I-D.ietf-lisp-ms]. 203 o The Map-Resolver decapsulates the ECM message, decrypts the OTK, 204 if needed, and forwards through the Mapping System the received 205 Map-Request and the OTK, as part of a new ECM message. As 206 described in Section 5.5, the LISP Mapping System delivers the ECM 207 to the appropriate Map-Server, as identified by the EID 208 destination address of the Map-Request. 210 o The Map-Server is configured with the location mappings and policy 211 information for the ETR responsible for the destination EID 212 address. Using this preconfigured information the Map-Server, 213 after the decapsulation of the ECM message, finds the longest 214 match EID prefix that covers the requested EID in the received 215 Map-Request. The Map-Server adds this EID prefix, together with 216 an HMAC computed using the OTK, to a new Encapsulated Control 217 Message that contains the received Map-Request. 219 o The Map-Server derives a new OTK (OTK-ETR) by applying a Key 220 Derivation Function (KDF) to the OTK. This new OTK is included in 221 the Encapsulated Control Message sent to the ETR. To provide OTK 222 confidentiality over the path between the Map-Server and the ETR, 223 the new OTK should be encrypted using the key shared between the 224 ETR and the Map-Server in order to secure ETR registration 225 [I-D.ietf-lisp-ms]. 227 o If the Map-Server is acting in proxy mode, as specified in 228 [I-D.ietf-lisp], the ETR is not involved in the origination of the 229 Map-Reply. In this case the Map-Server originates the Map-Reply 230 on behalf of the ETR as described below. 232 o The ETR, upon receiving the Encapsulated Map-Request from the Map- 233 Server, decrypts the OTK-ETR, if needed, and originates a Map- 234 Reply that contains the EID-to-RLOC mapping information as 235 specified in [I-D.ietf-lisp]. 237 o The ETR computes an HMAC over the original LISP Map-Reply, keyed 238 with OTK-ETR to protect the integrity of the whole Map-Reply. The 239 ETR also copies the EID prefix authorization data that the Map- 240 Server included in the Encapsulated Map-Request into the Map-Reply 241 message. 243 o The ITR, upon receiving the Map-Reply, uses the locally stored OTK 244 to verify the integrity of the EID prefix authorization data 245 included in the Map-Reply by the Map-Server. The ITR computes 246 OTK-ETR by applying the same KDF used by the Map-Server, and 247 verifies the integrity of the Map-Reply. If the integrity checks 248 fail the Map-Reply MUST be discarded. Also, if the EID prefix 249 claimed by the ETR in the Map-Reply is less specific than the EID 250 prefix authorization data inserted by the Map-Server, the ITR MUST 251 discard the Map-Reply. 253 5. LISP-SEC Control Messages Details 255 LISP-SEC metadata associated with a Map-Request is transported within 256 the Encapsulated Control Message that contains the Map-Request. 258 LISP-SEC metadata associated with the Map-Reply is transported within 259 the Map-Reply itself. 261 5.1. Encapsulated Control Message LISP-SEC Extensions 263 LISP-SEC uses the ECM (Encapsulated Control Message) defined in 264 [I-D.ietf-lisp] with Type set to 8, and S bit set to 1 to indicate 265 that the LISP header includes Authentication Data (AD). The format 266 of the LISP-SEC ECM Authentication Data is defined in the following 267 figure. OTK-AD stands for One-Time Key Authentication Data and 268 EID-AD stands for EID Authentication Data. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | AD Type |V| Reserved | Requested HMAC ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 275 | OTK Length | OTK Encryption ID | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 277 | One-Time-Key Preamble ... | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTK-AD 279 | ... One-Time-Key Preamble | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 281 ~ One-Time Key (128 bits) ~/ 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 283 | EID AD Length | KDF ID | | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 285 | Reserved | EID HMAC ID | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 287 | Reserved | EID mask-len | EID-AFI | EID-AD 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 289 ~ EID prefix ... ~ | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 291 ~ EID HMAC (160 bits) ~ | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 294 LISP-SEC ECM Authentication Data 296 AD Type: 1 (LISP-SEC Authentication Data) 298 V: Key Version bit. This bit is toggled when the sender switches 299 to a new OTK wrapping key 301 Reserved: Set to 0 on transmission and ignored on receipt. 303 Requested HMAC ID: the HMAC algorithm requested by the ITR. See 304 Section 5.3 for details. 306 OTK Length: The length (in bytes) of the OTK Authentication Data 307 (OTK-AD), that contains the OTK Preamble and the OTK. 309 OTK Encryption ID: The identifier of the key wrapping algorithm 310 used to encrypt the One-Time-Key. When a 128-bit OTK is sent 311 unencrypted by the Map-Resolver, the OTK Encryption ID is set to 312 NULL_KEY_WRAP_128. See Section 5.4 for more details. 314 One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When 315 the OTK is encrypted, this field may carry additional metadata 316 resulting from the key wrapping operation. When a 128-bit OTK is 317 sent unencrypted by Map-Resolver, the OTK Preamble is set to 318 0x0000000000000000 (64 bits). See Section 5.4 for details. 320 One-Time-Key: the OTK encrypted (or not) as specified by OTK 321 Encryption ID. See Section 5.4 for details. 323 EID AD Length: length (in bytes) of the EID Authentication Data 324 (EID-AD). The ITR MUST set EID AD Length to 32, as it only fills 325 the KDF ID field, and all the remaining fields part of the EID-AD 326 are not present. 328 KDF ID: Identifier of the Key Derivation Function used to derive 329 OTK-ETR. The ITR SHOULD use this field to indicate the 330 recommended KDF algorithm, according to local policy. The Map- 331 Server can overwrite the KDF ID if it does not support the KDF ID 332 recommended by the ITR. See Section 5.4 for more details. 334 Reserved: Set to 0 on transmission and ignored on receipt. 336 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 337 integrity of the EID prefix authorization fields. This field is 338 filled by Map-Server that computed the EID prefix HMAC. See 339 Section 5.4 for more details. 341 EID mask-len: Mask length for EID prefix. 343 EID-AFI: Address family of EID-prefix according to [RFC5226] 345 EID prefix: The Map-Server uses this field to specify the EID 346 prefix that the destination ETR is authoritative for, and is the 347 longest match for the requested EID. 349 EID HMAC: HMAC of the EID prefix authorization fields that is 350 computed and inserted by Map-Server. Before computing the HMAC 351 operation the EID HMAC field MUST be set to 0. The HMAC covers 352 the entire EID-AD. 354 5.2. Map-Reply LISP-SEC Extensions 356 LISP-SEC uses the Map-Reply defined in [I-D.ietf-lisp], with Type set 357 to 2, and S bit set to 1 to indicate that the Map-Reply message 358 includes Authentication Data (AD). The format of the LISP-SEC Map- 359 Reply Authentication Data is defined in the following figure. LOC-AD 360 stands for LOC Authentication Data. 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | AD Type | Reserved | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\ 367 | EID AD Length | KDF ID | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 369 | Reserved | EID HMAC ID | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 371 | Reserved | EID mask-len | EID-AFI | EID-AD 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 373 ~ EID prefix ... ~ | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 375 ~ EID HMAC (160 bits) ~ | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 377 | LOC AD Length | LOC HMAC ID |\ 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 379 ~ LOC HMAC (160 bits) ~ LOC-AD 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/ 382 LISP-SEC Map-Reply Authentication Data 384 AD Type: 1 (LISP-SEC Authentication Data) 386 EID AD Length: length (in bytes) of the EID-AD. 388 KDF ID: Identifier of the Key Derivation Function used to derive 389 OTK-ETR. See Section 5.6 for more details. 391 Reserved: Set to 0 on transmission and ignored on receipt. 393 EID HMAC ID: Identifier of the HMAC algorithm used to protect the 394 integrity of the EID prefix authorization fields. See Section 5.6 395 for more details. 397 EID mask-len: Mask length for EID prefix. 399 EID-AFI: Address family of EID-prefix according to [RFC5226]. 401 EID prefix: This field contains the EID prefix that the 402 destination ETR is authoritative for, and is the longest match for 403 the requested EID. 405 EID HMAC: HMAC of the EID prefix authorization fields. Before 406 computing the HMAC operation the EID HMAC field MUST be set to 0. 408 LOC AD Length: length (in bytes) of the Map-Reply Location 409 Authentication Data (LOC-AD). 411 LOC HMAC ID: Identifier of the HMAC algorithm used to protect the 412 integrity of the Map-reply Location Data. 414 LOC HMAC: HMAC of the Map-reply Location Data. The scope of the 415 authentication covers the whole Map-Reply Payload (from Type to 416 Mapping Protocol Data fields included). See Section 5.7 for more 417 details. 419 5.3. ITR Processing 421 Upon creating a Map-Request, the ITR generates a random OTK that is 422 stored locally, together with the nonce generated as specified in 423 [I-D.ietf-lisp]. 425 The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 426 1, to indicate the presence of Authentication Data. If the ITR and 427 the Map-Resolver are configured with a shared key, the OTK 428 confidentiality SHOULD be protected by wrapping the OTK with the 429 algorithm specified by the OTK Encryption ID field. See Section 5.4 430 for further details on OTK encryption. 432 The Requested HMAC ID field contains the suggested HMAC algorithm to 433 be used by the Map-Server and the ETR to protect the integrity of the 434 ECM Authentication data and of the Map-Reply. 436 The KDF ID field, specifies the suggested key derivation function to 437 be used by the Map-Server to derive the OTK-ETR. 439 The EID AD length is set to 32, since the Authentication Data does 440 not contain EID prefix Authentication Data, and the EID-AD contains 441 only the KDF ID field. 443 In response to an encapsulated Map-Request that has the S-bit set, an 444 ITR MUST receive a Map-Reply with the S-bit set, that includes an EID 445 AD and a LOC AD. If the Map-Reply does not include both ADs, the ITR 446 MUST discard it. In response to an encapsulated Map-Request with 447 S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and 448 the ITR SHOULD discard the Map-Reply if the S-bit is set. 450 Upon receiving a Map-Reply, the ITR must verify the integrity of both 451 the EID-AD and the LOC-AD, and MUST discard the Map-Reply if one of 452 the integrity checks fails. 454 The integrity of the EID-AD is verified using the locally stored OTK 455 to re-compute the HMAC of the EID-AD using the Algorithm specified in 456 the EID HMAC ID field. If the EID HMAC ID field does not match the 457 Requested HMAC ID the ITR SHOULD discard the Map-Reply and send a new 458 Map-Request with a different Requested HMAC ID field, according to 459 ITR's local policy. The ITR MUST set the EID HMAC ID field to 0 460 before computing the HMAC. 462 To verify the integrity of the LOC-AD, first the OTK-ETR is derived 463 from the locally stored OTK using the algorithm specified in the KDF 464 ID field. This is because the LOC AD is generated by the ETR using 465 the OTK-ETR. If the KDF ID in the Map-Reply does not match the KDF 466 ID requested in the Map-Request, the ITR SHOULD discard the Map- 467 Reply, and send a new Map-Request with a different KDF ID, according 468 to ITR's local policy. The derived OTK-ETR is then used to re- 469 compute the HMAC of the LOC-AD using the Algorithm specified in the 470 LOC HMAC ID field. If the LOC HMAC ID field does not match the 471 Requested HMAC ID the ITR SHOULD discard the Map-Reply, and send a 472 new Map-Request with a new Required HMAC ID according to ITR's local 473 policy. 475 The Map-Reply is considered a valid Map-Reply only if: (1) both 476 EID-AD and LOC-AD are valid, and (2) the EID prefixes in the Map- 477 Reply records are equal to or more specific than the EID prefix in 478 the EID-AD. After identifying the Map-Reply as valid, the ITR 479 proceeds to adding the Map-Reply records to its EID-to-RLOC cache, as 480 described in [I-D.ietf-lisp]. 482 The ITR SHOULD send SMR triggered Map Requests over the mapping 483 system in order to receive a secure Map-Reply. If an ITR accepts 484 piggybacked Map-Replies, it SHOULD also send a Map-Request over the 485 mapping system in order to securely verify the piggybacked Map-Reply. 487 5.4. Encrypting and Decrypting an OTK 489 If OTK confidentiality is required in the path between the Map-Server 490 and the ETR, the OTK SHOULD be encrypted using the preconfigured key 491 shared between the Map-Server and the ETR for the purpose of securing 492 ETR registration [I-D.ietf-lisp-ms]. Similarly, if OTK 493 confidentiality is required in the path between the ITR and the Map- 494 Resolver, the OTK SHOULD be encrypted with a key shared between the 495 ITR and the Map-Resolver. 497 The OTK is encrypted using the algorithm specified in the OTK 498 Encryption ID field. When the AES Key Wrap algorithm is used to 499 encrypt a 128-bit OTK, according to [RFC3339], the AES Key Wrap 500 Initialization Value MUST be set to 0xA6A6A6A6A6A6A6A6 (64 bits). 501 The output of the AES Key Wrap operation is 192-bit long. The most 502 significant 64-bit are copied in the One-Time Key Preamble field, 503 while the 128 less significant bits are copied in the One-Time Key 504 field of the LISP-SEC Authentication Data. 506 When decrypting an encrypted OTK the receiver MUST verify that the 507 Initialization Value resulting from the AES Key Wrap decryption 508 operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails 509 the receiver MUST discard the entire message. 511 When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set 512 to NULL_KEY_WRAP_128, and the OTK Preamble is set to 513 0x0000000000000000 (64 bits). 515 5.5. Map-Resolver Processing 517 Upon receiving an encapsulated Map-Request with the S-bit set, the 518 Map-Resolver decapsulates the ECM message. The OTK, if encrypted, is 519 decrypted as specified in Section 5.4. 521 The Map-Resolver, as specified in [I-D.ietf-lisp-ms], originates a 522 new ECM header with the S-bit set, that contains the unencrypted OTK, 523 as specified in Section 5.4, and the other data derived from the ECM 524 Authentication Data of the received encapsulated Map-Request. 526 The Map-Resolver then forwards the received Map-Request, encapsulated 527 in the new ECM header that includes the newly computed Authentication 528 Data fields. 530 5.6. Map-Server Processing 532 Upon receiving an encapsulated Map-Request with the S-bit set, the 533 Map-Server decapsulates the ECM and generates a new ECM 534 Authentication Data. The Authentication Data includes the OTK-AD and 535 the EID-AD, that contains EID prefix authorization information, that 536 are ultimately sent to the requesting ITR. 538 The Map-Server updates the OTK-AD by deriving a new OTK (OTK-ETR) 539 from the OTK received with the Map-Request. OTK-ETR is derived 540 applying the key derivation function specified in the KDF ID field. 541 If the algorithm specified in the KDF ID field is not supported, the 542 Map-Server uses a different algorithm to derive the key and updates 543 the KDF ID field accordingly. 545 The Map-Server and the ETR MUST be configured with a shared key for 546 mapping registration according to [I-D.ietf-lisp-ms]. If OTK 547 confidentiality is required, then the OTK-ETR SHOULD be encrypted, by 548 wrapping the OTK-ETR with the algorithm specified by the OTK 549 Encryption ID field as specified in Section 5.4. 551 The Map-Server includes in the EID AD the longest match registered 552 EID prefix for the destination EID, and an HMAC of this EID prefix. 553 The HMAC is keyed with the OTK in the ECM Authentication Data that is 554 received from ITR, and the HMAC algorithm is chosen according to the 555 Requested HMAC ID field. If The Map-Server does not support this 556 algorithm, the Map-Server uses a different algorithm and specifies it 557 in the EID HMAC ID field. The scope of the HMAC operation covers the 558 entire EID-AD, from the EID-AD Length field to the EID HMAC field, 559 which must be set to 0 before the computation. 561 The Map-Server then forwards the updated ECM encapsulated Map- 562 Request, that contains the OTK-AD, the EID-AD, and the received Map- 563 Request to an authoritative ETR as specified in [I-D.ietf-lisp]. 565 5.6.1. Map-Server Processing in Proxy mode 567 If the Map-Server is in proxy mode, it generates a Map-Reply, as 568 specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply 569 includes the Authentication Data that contains the EID AD, computed 570 as specified in Section 5.6, as well as the LOC-AD computed as 571 specified in Section 5.7. 573 5.7. ETR Processing 575 Upon receiving an encapsulated Map-Request with the S-bit set, the 576 ETR decapsulates the ECM message. The OTK field, if encrypted, is 577 decrypted as specified in Section 5.4 to obtain the unencrypted OTK- 578 ETR. 580 The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp] 581 and includes an Authentication Data that contains the EID-AD, as 582 received in the encapsulated Map-Request, as well as the LOC-AD. 584 The EID-AD is copied from the Authentication Data of the received 585 encapsulated Map-Request. 587 The LOC-AD contains the HMAC of the whole Map-Reply message, keyed 588 with the OTK-ETR and computed using the HMAC algorithm specified in 589 the Requested HMAC ID field of the received encapsulated Map-Request. 590 If the ETR does not support the Requested HMAC ID, it uses a 591 different algorithm and updates the LOC HMAC ID field accordingly. 592 Finally the ETR sends the Map-Reply to the requesting ITR as 593 specified in [I-D.ietf-lisp]. 595 6. Security Considerations 597 6.1. Mapping System Security 599 The LISP-SEC threat model described in Section 3, assumes that the 600 LISP Mapping System is working properly and eventually delivers Map- 601 Request messages to a Map-Server that is authoritative for the 602 requested EID. 604 Security is not yet embedded in LISP+ALT but BGP route filtering 605 SHOULD be deployed in the ALT infrastructure to enforce proper 606 routing in the mapping system. The SIDR working group is currently 607 addressing prefix and route advertisement authorization and 608 authentication for BGP. While following SIDR recommendations in the 609 global Internet will take time, applying these recommendations to the 610 ALT, which relies on BGP, should be less complex, as ALT is currently 611 small and with a limited number of operators. Ultimately, deploying 612 the SIDR recommendations in ALT further ensures that the fore 613 mentioned assumption is true. 615 It is also assumed that no man-in-the-middle attack can be carried 616 out against the ALT router to ALT router tunnels, and that the 617 information included into the Map-Requests, in particular the OTK, 618 cannot be read by third-party entities. It should be noted that the 619 integrity of the Map-Request in the ALT is protected by BGP 620 authentication, and that in order to provide OTK confidentiality in 621 the ALT mapping system the ALT router to ALT router tunnels MAY be 622 deployed using GRE+IPSec. 624 6.2. Random Number Generation 626 The OTK MUST be generated by a properly seeded pseudo-random (or 627 strong random) source. See [RFC4086] for advice on generating 628 security-sensitive random data 630 7. IANA Considerations 632 7.1. HMAC functions 634 The following HMAC ID values are defined by this memo for use as 635 Requested HMAC ID, EID HMAC ID, and LOC HMAC ID in the LISP-SEC 636 Authentication Data: 638 Name Number Defined In 639 ------------------------------------------------- 640 NONE 0 641 AUTH-HMAC-SHA-1-160 1 [RFC2104] 642 AUTH-HMAC-SHA-256-128 2 [RFC4634] 644 values 2-65535 are reserved to IANA. 646 HMAC Functions 648 AUTH-HMAC-SHA-1-160 MUST be supported, AUTH-HMAC-SHA-256-128 should 649 be supported. 651 7.2. Key Wrap Functions 653 The following OTK Encryption ID values are defined by this memo for 654 use as OTK key wrap algorithms ID in the LISP-SEC Authentication 655 Data: 657 Name Number Defined In 658 ------------------------------------------------- 659 NULL-KEY-WRAP-128 1 660 AES-KEY-WRAP-128 2 [RFC3394] 662 values 0 and 3-65535 are reserved to IANA. 664 Key Wrap Functions 666 NULL-KEY-WRAP-128, and AES-KEY-WRAP-128 MUST be supported. 668 NULL-KEY-WRAP-128 is used to carry an unencrypted 128-bit OTK, with a 669 64-bit preamble set to 0x0000000000000000 (64 bits). 671 7.3. Key Derivation Functions 673 The following KDF ID values are defined by this memo for use as KDF 674 ID in the LISP-SEC Authentication Data: 676 Name Number Defined In 677 ------------------------------------------------- 678 NONE 0 679 HKDF-SHA1-128 1 [RFC5869] 681 values 2-65535 are reserved to IANA. 683 Key Derivation Functions 685 HKDF-SHA1-128 MUST be supported 687 8. Acknowledgements 689 The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino 690 Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt 691 Noll for their valuable suggestions provided during the preparation 692 of this document. 694 9. Normative References 696 [I-D.ietf-lisp] 697 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 698 "Locator/ID Separation Protocol (LISP)", 699 draft-ietf-lisp-10 (work in progress), March 2011. 701 [I-D.ietf-lisp-interworking] 702 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 703 "Interworking LISP with IPv4 and IPv6", 704 draft-ietf-lisp-interworking-01 (work in progress), 705 August 2010. 707 [I-D.ietf-lisp-ms] 708 Fuller, V. and D. Farinacci, "LISP Map Server", 709 draft-ietf-lisp-ms-06 (work in progress), October 2010. 711 [I-D.saucez-lisp-security] 712 Saucez, D., Iannone, L., and O. Bonaventure, "LISP 713 Security Threats", draft-saucez-lisp-security-02 (work in 714 progress), January 2011. 716 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 717 Hashing for Message Authentication", RFC 2104, 718 February 1997. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, March 1997. 723 [RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard 724 (AES) Key Wrap Algorithm", RFC 3394, September 2002. 726 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 727 Requirements for Security", BCP 106, RFC 4086, June 2005. 729 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 730 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 731 May 2008. 733 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 734 Key Derivation Function (HKDF)", RFC 5869, May 2010. 736 Authors' Addresses 738 Fabio Maino 739 Cisco Systems 740 170 Tasman Drive 741 San Jose, California 95134 742 USA 744 Email: fmaino@cisco.com 746 Vina Ermagan 747 Cisco Systems 748 170 Tasman Drive 749 San Jose, California 95134 750 USA 752 Email: vermagan@cisco.com 754 Albert Cabellos 755 Technical University of Catalonia 756 c/ Jordi Girona s/n 757 Barcelona, 08034 758 Spain 760 Email: acabello@ac.upc.edu 762 Damien Saucez 763 Universite catholique de Louvain 764 Place St. Barbe 2 765 Louvain-la-Neuve, 766 Belgium 768 Email: damien.saucez@uclouvain.be 770 Olivier Bonaventure 771 Universite catholique de Louvain 772 Place St. Barbe 2 773 Louvain-la-Neuve, 774 Belgium 776 Email: olivier.bonaventure@uclouvain.be