--- 1/draft-ietf-lisp-sec-01.txt 2012-03-13 01:14:02.074671033 +0100 +++ 2/draft-ietf-lisp-sec-02.txt 2012-03-13 01:14:02.110672017 +0100 @@ -1,24 +1,25 @@ Network Working Group F. Maino Internet-Draft V. Ermagan Intended status: Experimental Cisco Systems -Expires: July 4, 2012 A. Cabellos +Expires: September 13, 2012 A. Cabellos Technical University of Catalonia D. Saucez + INRIA O. Bonaventure Universite catholique de Louvain - January 1, 2012 + March 12, 2012 LISP-Security (LISP-SEC) - draft-ietf-lisp-sec-01.txt + draft-ietf-lisp-sec-02.txt Abstract This memo specifies LISP-SEC, a set of security mechanisms that provide origin authentication, integrity and anti-replay protection to LISP's EID-to-RLOC mapping data conveyed via mapping lookup process. LISP-SEC also enables verification of authorization on EID- prefix claims in Map-Reply messages. Requirements Language @@ -35,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 4, 2012. + This Internet-Draft will expire on September 13, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect @@ -60,36 +61,37 @@ Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 3. LISP-SEC Threat Model . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 4 5. LISP-SEC Control Messages Details . . . . . . . . . . . . . . 7 5.1. Encapsulated Control Message LISP-SEC Extensions . . . . . 7 5.2. Map-Reply LISP-SEC Extensions . . . . . . . . . . . . . . 9 - 5.3. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10 - 5.3.1. Map-Reply Record Validation . . . . . . . . . . . . . 12 - 5.3.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13 - 5.4. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13 - 5.5. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 - 5.6. Map-Server Processing . . . . . . . . . . . . . . . . . . 14 - 5.6.1. Map-Server Processing in Proxy mode . . . . . . . . . 15 - 5.7. ETR Processing . . . . . . . . . . . . . . . . . . . . . . 15 + 5.3. Map-Register LISP-SEC Extentions . . . . . . . . . . . . . 10 + 5.4. ITR Processing . . . . . . . . . . . . . . . . . . . . . . 10 + 5.4.1. Map-Reply Record Validation . . . . . . . . . . . . . 12 + 5.4.2. PITR Processing . . . . . . . . . . . . . . . . . . . 13 + 5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . . 13 + 5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 14 + 5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 14 + 5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 15 + 5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.1. Mapping System Security . . . . . . . . . . . . . . . . . 16 6.2. Random Number Generation . . . . . . . . . . . . . . . . . 16 - 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 16 + 6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7.1. HMAC functions . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Key Wrap Functions . . . . . . . . . . . . . . . . . . . . 17 - 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . . 17 + 7.3. Key Derivation Functions . . . . . . . . . . . . . . . . . 18 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Normative References . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction The Locator/ID Separation Protocol [I-D.ietf-lisp] defines a set of functions for routers to exchange information used to map from non- routable Endpoint Identifiers (EIDs) to routable Routing Locators (RLOCs). If these EID-to-RLOC mappings, carried through Map-Reply @@ -220,21 +222,21 @@ sent to the Map-Resolver. To provide confidentiality to the ITR- OTK over the path between the ITR and its Map-Resolver, the ITR- OTK SHOULD be encrypted using a preconfigured key shared between the ITR and the Map-Resolver, similar to the key shared between the ETR and the Map-Server in order to secure ETR registration [I-D.ietf-lisp-ms]. o The Map-Resolver decapsulates the ECM message, decrypts the ITR- OTK, if needed, and forwards through the Mapping System the received Map-Request and the ITR-OTK, as part of a new ECM - message. As described in Section 5.5, the LISP Mapping System + message. As described in Section 5.6, the LISP Mapping System delivers the ECM to the appropriate Map-Server, as identified by the EID destination address of the Map-Request. o The Map-Server is configured with the location mappings and policy information for the ETR responsible for the destination EID address. Using this preconfigured information the Map-Server, after the decapsulation of the ECM message, finds the longest match EID-prefix that covers the requested EID in the received Map-Request. The Map-Server adds this EID-prefix, together with an HMAC computed using the ITR-OTK, to a new Encapsulated Control @@ -318,38 +320,38 @@ LISP-SEC ECM Authentication Data AD Type: 1 (LISP-SEC Authentication Data) V: Key Version bit. This bit is toggled when the sender switches to a new OTK wrapping key Reserved: Set to 0 on transmission and ignored on receipt. Requested HMAC ID: The HMAC algorithm requested by the ITR. See - Section 5.3 for details. + Section 5.4 for details. OTK Length: The length (in bytes) of the OTK Authentication Data (OTK-AD), that contains the OTK Preamble and the OTK. OTK Encryption ID: The identifier of the key wrapping algorithm used to encrypt the One-Time-Key. When a 128-bit OTK is sent unencrypted by the Map-Resolver, the OTK Encryption ID is set to - NULL_KEY_WRAP_128. See Section 5.4 for more details. + NULL_KEY_WRAP_128. See Section 5.5 for more details. One-Time-Key Preamble: set to 0 if the OTK is not encrypted. When the OTK is encrypted, this field may carry additional metadata resulting from the key wrapping operation. When a 128-bit OTK is sent unencrypted by Map-Resolver, the OTK Preamble is set to - 0x0000000000000000 (64 bits). See Section 5.4 for details. + 0x0000000000000000 (64 bits). See Section 5.5 for details. One-Time-Key: the OTK encrypted (or not) as specified by OTK - Encryption ID. See Section 5.4 for details. + Encryption ID. See Section 5.5 for details. EID-AD Length: length (in bytes) of the EID Authentication Data (EID-AD). The ITR MUST set EID-AD Length to 4 bytes, as it only fills the KDF ID field, and all the remaining fields part of the EID-AD are not present. An EID-AD MAY contain multiple EID- records. Each EID-record is 4-byte long plus the length of the AFI-encoded EID-prefix. KDF ID: Identifier of the Key Derivation Function used to derive the MS-OTK. The ITR SHOULD use this field to indicate the @@ -408,30 +410,30 @@ LISP-SEC Map-Reply Authentication Data AD Type: 1 (LISP-SEC Authentication Data) EID-AD Length: length (in bytes) of the EID-AD. An EID-AD MAY contain multiple EID-records. Each EID-record is 4-byte long plus the length of the AFI-encoded EID-prefix. KDF ID: Identifier of the Key Derivation Function used to derive - MS-OTK. See Section 5.6 for more details. + MS-OTK. See Section 5.7 for more details. Record Count: The number of records in this Map-Reply message. A record is comprised of the portion of the packet that is labeled 'Rec' above and occurs the number of times equal to Record Count. Reserved: Set to 0 on transmission and ignored on receipt. EID HMAC ID: Identifier of the HMAC algorithm used to protect the - integrity of the EID-AD. See Section 5.6 for more details. + integrity of the EID-AD. See Section 5.7 for more details. EID mask-len: Mask length for EID-prefix. EID-AFI: Address family of EID-prefix according to [RFC5226]. EID-prefix: This field contains an EID-prefix that the destination ETR is authoritative for, and is the longest match for the requested EID. EID HMAC: HMAC of the EID-AD, as computed by the Map-Server. @@ -441,33 +443,40 @@ PKT-AD Length: length (in bytes) of the Packet Authentication Data (PKT-AD). PKT HMAC ID: Identifier of the HMAC algorithm used to protect the integrity of the Map-reply Location Data. PKT HMAC: HMAC of the whole Map-Reply packet, including the LISP- SEC Authentication Data. The scope of the authentication goes from the Map-Reply Type field to the PKT HMAC field included. Before computing the HMAC operation the PKT HMAC field MUST be set - to 0. See Section 5.7 for more details. + to 0. See Section 5.8 for more details. -5.3. ITR Processing +5.3. Map-Register LISP-SEC Extentions + + The second bit after the Type field in a Map-Register message is + allocated as the S bit. The S bit indicates to the Map-Server that + the registering ETR is LISP-SEC enabled. An ETR that supports LISP- + SEC MUST set the S bit in its Map-Register messages. + +5.4. ITR Processing Upon creating a Map-Request, the ITR generates a random ITR-OTK that is stored locally, together with the nonce generated as specified in [I-D.ietf-lisp]. The Map-Request MUST be encapsulated in an ECM, with the S-bit set to 1, to indicate the presence of Authentication Data. If the ITR and the Map-Resolver are configured with a shared key, the ITR-OTK confidentiality SHOULD be protected by wrapping the ITR-OTK with the - algorithm specified by the OTK Encryption ID field. See Section 5.4 + algorithm specified by the OTK Encryption ID field. See Section 5.5 for further details on OTK encryption. The Requested HMAC ID field contains the suggested HMAC algorithm to be used by the Map-Server and the ETR to protect the integrity of the ECM Authentication data and of the Map-Reply. The KDF ID field, specifies the suggested key derivation function to be used by the Map-Server to derive the MS-OTK. The EID-AD length is set to 4 bytes, since the Authentication Data @@ -509,28 +518,28 @@ ITR's local policy. Each individual Map-Reply EID-record is considered valid only if: (1) both EID-AD and PKT-AD are valid, and (2) the intersection of the EID-prefix in the Map-Reply EID-record with one of the EID-prefixes contained in the EID-AD is not empty. After identifying the Map- Reply record as valid, the ITR sets the EID-prefix in the Map-Reply record to the value of the intersection set computed before, and adds the Map-Reply EID-record to its EID-to-RLOC cache, as described in [I-D.ietf-lisp]. An example of Map-Reply record validation is - provided in Section 5.3.1. + provided in Section 5.4.1. The ITR SHOULD send SMR triggered Map Requests over the mapping system in order to receive a secure Map-Reply. If an ITR accepts piggybacked Map-Replies, it SHOULD also send a Map-Request over the mapping system in order to securely verify the piggybacked Map-Reply. -5.3.1. Map-Reply Record Validation +5.4.1. Map-Reply Record Validation The payload of a Map-Reply may contain multiple EID-records. The whole Map-Reply is signed by the ETR, with the PKT HMAC, to provide integrity protection and origin authentication to the EID-prefix records claimed by the ETR. The Authentication Data field of a Map- Reply may contain multiple EID-records in the EID-AD. The EID-AD is signed by the Map-Server, with the EID HMAC, to provide integrity protection and origin authentication to the EID-prefix records inserted by the Map-Server. @@ -565,29 +573,29 @@ The EID-record with EID-prefix 1.1.2.0/24 is stored in the map-cache because it matches the second EID-prefix contained in the EID-AD. The EID-record with EID-prefix 1.2.0.0/16 is not processed since it is not included in any of the EID-ADs signed by the Map-Server. A log message is issued. In this last example the ETR is trying to over claim the EID-prefix 1.2.0.0/16, but the Map-Server authorized only 1.2.3.0/24, hence the EID-record is discarded. -5.3.2. PITR Processing +5.4.2. PITR Processing The processing performed by a PITR is equivalent to the processing of an ITR. However, if the PITR is directly connected to the ALT, the PITR performs the functions of both the ITR and the Map-Resolver forwarding the Map-Request encapsulated in an ECM header that - includes the Authentication Data fields as described in Section 5.5. + includes the Authentication Data fields as described in Section 5.6. -5.4. Encrypting and Decrypting an OTK +5.5. Encrypting and Decrypting an OTK MS-OTK confidentiality is required in the path between the Map-Server and the ETR, the MS-OTK SHOULD be encrypted using the preconfigured key shared between the Map-Server and the ETR for the purpose of securing ETR registration [I-D.ietf-lisp-ms]. Similarly, if ITR-OTK confidentiality is required in the path between the ITR and the Map- Resolver, the ITR-OTK SHOULD be encrypted with a key shared between the ITR and the Map-Resolver. The OTK is encrypted using the algorithm specified in the OTK @@ -601,36 +609,36 @@ When decrypting an encrypted OTK the receiver MUST verify that the Initialization Value resulting from the AES Key Wrap decryption operation is equal to 0xA6A6A6A6A6A6A6A6. If this verification fails the receiver MUST discard the entire message. When a 128-bit OTK is sent unencrypted the OTK Encryption ID is set to NULL_KEY_WRAP_128, and the OTK Preamble is set to 0x0000000000000000 (64 bits). -5.5. Map-Resolver Processing +5.6. Map-Resolver Processing Upon receiving an encapsulated Map-Request with the S-bit set, the Map-Resolver decapsulates the ECM message. The ITR-OTK, if - encrypted, is decrypted as specified in Section 5.4. + encrypted, is decrypted as specified in Section 5.5. The Map-Resolver, as specified in [I-D.ietf-lisp-ms], originates a new ECM header with the S-bit set, that contains the unencrypted ITR- - OTK, as specified in Section 5.4, and the other data derived from the + OTK, as specified in Section 5.5, and the other data derived from the ECM Authentication Data of the received encapsulated Map-Request. The Map-Resolver then forwards the received Map-Request, encapsulated in the new ECM header that includes the newly computed Authentication Data fields. -5.6. Map-Server Processing +5.7. Map-Server Processing Upon receiving an ECM encapsulated Map-Request with the S-bit set, the Map-Server process the Map-Request according to the value of the S-bit contained in the Map-Register sent by the ETR during registration. If the S-bit contained in the Map-Register was clear the Map-Server decapsulates the ECM and generates a new ECM encapsulated Map-Request that does not contain an ECM Authentication Data, as specified in [I-D.ietf-lisp]. The Map-Server does not perform any further LISP- @@ -646,49 +654,49 @@ the ITR-OTK received with the Map-Request. MS-OTK is derived applying the key derivation function specified in the KDF ID field. If the algorithm specified in the KDF ID field is not supported, the Map-Server uses a different algorithm to derive the key and updates the KDF ID field accordingly. The Map-Server and the ETR MUST be configured with a shared key for mapping registration according to [I-D.ietf-lisp-ms]. If MS-OTK confidentiality is required, then the MS-OTK SHOULD be encrypted, by wrapping the MS-OTK with the algorithm specified by the OTK - Encryption ID field as specified in Section 5.4. + Encryption ID field as specified in Section 5.5. The Map-Server includes in the EID-AD the longest match registered EID-prefix for the destination EID, and an HMAC of this EID-prefix. The HMAC is keyed with the ITR-OTK contained in the received ECM Authentication Data, and the HMAC algorithm is chosen according to the Requested HMAC ID field. If The Map-Server does not support this algorithm, the Map-Server uses a different algorithm and specifies it in the EID HMAC ID field. The scope of the HMAC operation covers the entire EID-AD, from the EID-AD Length field to the EID HMAC field, which must be set to 0 before the computation. The Map-Server then forwards the updated ECM encapsulated Map- Request, that contains the OTK-AD, the EID-AD, and the received Map- Request to an authoritative ETR as specified in [I-D.ietf-lisp]. -5.6.1. Map-Server Processing in Proxy mode +5.7.1. Map-Server Processing in Proxy mode If the Map-Server is in proxy mode, it generates a Map-Reply, as specified in [I-D.ietf-lisp], with the S-bit set to 1. The Map-Reply includes the Authentication Data that contains the EID-AD, computed - as specified in Section 5.6, as well as the PKT-AD computed as - specified in Section 5.7. + as specified in Section 5.7, as well as the PKT-AD computed as + specified in Section 5.8. -5.7. ETR Processing +5.8. ETR Processing Upon receiving an encapsulated Map-Request with the S-bit set, the ETR decapsulates the ECM message. The OTK field, if encrypted, is - decrypted as specified in Section 5.4 to obtain the unencrypted MS- + decrypted as specified in Section 5.5 to obtain the unencrypted MS- OTK. The ETR then generates a Map-Reply as specified in [I-D.ietf-lisp] and includes an Authentication Data that contains the EID-AD, as received in the encapsulated Map-Request, as well as the PKT-AD. The EID-AD is copied from the Authentication Data of the received encapsulated Map-Request. The PKT-AD contains the HMAC of the whole Map-Reply packet, keyed @@ -866,33 +874,33 @@ Email: fmaino@cisco.com Vina Ermagan Cisco Systems 170 Tasman Drive San Jose, California 95134 USA Email: vermagan@cisco.com - Albert Cabellos Technical University of Catalonia c/ Jordi Girona s/n Barcelona, 08034 Spain Email: acabello@ac.upc.edu + Damien Saucez - Universite catholique de Louvain - Place St. Barbe 2 - Louvain-la-Neuve, - Belgium + INRIA + 2004 route des Lucioles - BP 93 + Sophia Antipolis, + France - Email: damien.saucez@uclouvain.be + Email: damien.saucez@inria.fr Olivier Bonaventure Universite catholique de Louvain Place St. Barbe 2 Louvain-la-Neuve, Belgium Email: olivier.bonaventure@uclouvain.be