Diff: draft-ietf-lisp-sec-12.txt - draft-ietf-lisp-sec-13.txt

	draft-ietf-lisp-sec-12.txt	draft-ietf-lisp-sec-13.txt

	Network Working Group F. Maino	Network Working Group F. Maino
	Internet-Draft V. Ermagan	Internet-Draft V. Ermagan
	Intended status: Experimental Cisco Systems	Intended status: Experimental Cisco Systems

	Expires: May 20, 2017 A. Cabellos	Expires: March 24, 2018 A. Cabellos
	Technical University of Catalonia	Universitat Politecnica de Catalunya
	D. Saucez	D. Saucez
	INRIA	INRIA

	November 16, 2016	September 20, 2017

	LISP-Security (LISP-SEC)	LISP-Security (LISP-SEC)

	draft-ietf-lisp-sec-12	draft-ietf-lisp-sec-13

	Abstract	Abstract

	This memo specifies LISP-SEC, a set of security mechanisms that	This memo specifies LISP-SEC, a set of security mechanisms that
	provides origin authentication, integrity and anti-replay protection	provides origin authentication, integrity and anti-replay protection
	to LISP's EID-to-RLOC mapping data conveyed via mapping lookup	to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
	process. LISP-SEC also enables verification of authorization on EID-	process. LISP-SEC also enables verification of authorization on EID-
	prefix claims in Map-Reply messages.	prefix claims in Map-Reply messages.

	Requirements Language	Requirements Language

	skipping to change at page 1, line 37 ¶	skipping to change at page 1, line 37 ¶
	document are to be interpreted as described in [RFC2119].	document are to be interpreted as described in [RFC2119].

	Status of This Memo	Status of This Memo

	This Internet-Draft is submitted in full conformance with the	This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.	provisions of BCP 78 and BCP 79.

	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-

	Drafts is at http://datatracker.ietf.org/drafts/current/.	Drafts is at https://datatracker.ietf.org/drafts/current/.

	Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."	material or to cite them other than as "work in progress."


	This Internet-Draft will expire on May 20, 2017.	This Internet-Draft will expire on March 24, 2018.

	Copyright Notice	Copyright Notice


	Copyright (c) 2016 IETF Trust and the persons identified as the	Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents

	(http://trustee.ietf.org/license-info) in effect on the date of	(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3

	skipping to change at page 2, line 43 ¶	skipping to change at page 2, line 43 ¶
	5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14	5.5. Encrypting and Decrypting an OTK . . . . . . . . . . . . 14
	5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15	5.6. Map-Resolver Processing . . . . . . . . . . . . . . . . . 15
	5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15	5.7. Map-Server Processing . . . . . . . . . . . . . . . . . . 15
	5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16	5.7.1. Map-Server Processing in Proxy mode . . . . . . . . . 16
	5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16	5.8. ETR Processing . . . . . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17	6.1. Mapping System Security . . . . . . . . . . . . . . . . . 17
	6.2. Random Number Generation . . . . . . . . . . . . . . . . 17	6.2. Random Number Generation . . . . . . . . . . . . . . . . 17
	6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17	6.3. Map-Server and ETR Colocation . . . . . . . . . . . . . . 17
	6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17	6.4. Deploying LISP-SEC . . . . . . . . . . . . . . . . . . . 17

	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18	6.5. Provisioning of the shared keys . . . . . . . . . . . . . 18
	7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 18	6.6. Reply Attacks . . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 18	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
		7.1. ECM AD Type Registry . . . . . . . . . . . . . . . . . . 19
		7.2. Map-Reply AD Type Registry . . . . . . . . . . . . . . . 19
	7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19	7.3. HMAC Functions . . . . . . . . . . . . . . . . . . . . . 19

	7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 19	7.4. Key Wrap Functions . . . . . . . . . . . . . . . . . . . 20
	7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20	7.5. Key Derivation Functions . . . . . . . . . . . . . . . . 20

	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
	9. Normative References . . . . . . . . . . . . . . . . . . . . 20	9. Normative References . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22

	1. Introduction	1. Introduction

	The Locator/ID Separation Protocol [RFC6830] is a network-layer-based	The Locator/ID Separation Protocol [RFC6830] is a network-layer-based
	protocol that enables separation of IP addresses into two new	protocol that enables separation of IP addresses into two new
	numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators	numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators
	(RLOCs). EID-to-RLOC mappings are stored in a database, the LISP	(RLOCs). EID-to-RLOC mappings are stored in a database, the LISP
	Mapping System, and made available via the Map-Request/Map-Reply	Mapping System, and made available via the Map-Request/Map-Reply
	lookup process. If these EID-to-RLOC mappings, carried through Map-	lookup process. If these EID-to-RLOC mappings, carried through Map-

	skipping to change at page 12, line 18 ¶	skipping to change at page 12, line 18 ¶

	In response to an encapsulated Map-Request that has the S-bit set, an	In response to an encapsulated Map-Request that has the S-bit set, an
	ITR MUST receive a Map-Reply with the S-bit set, that includes an	ITR MUST receive a Map-Reply with the S-bit set, that includes an
	EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the	EID-AD and a PKT-AD. If the Map-Reply does not include both ADs, the
	ITR MUST discard it. In response to an encapsulated Map-Request with	ITR MUST discard it. In response to an encapsulated Map-Request with
	S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and	S-bit set to 0, the ITR expects a Map-Reply with S-bit set to 0, and
	the ITR SHOULD discard the Map-Reply if the S-bit is set.	the ITR SHOULD discard the Map-Reply if the S-bit is set.

	Upon receiving a Map-Reply, the ITR must verify the integrity of both	Upon receiving a Map-Reply, the ITR must verify the integrity of both
	the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of	the EID-AD and the PKT-AD, and MUST discard the Map-Reply if one of

	the integrity checks fails.	the integrity checks fails. After processing the Map-Reply, the ITR
		must discard the <nonce,ITK-OTK> pair associated to the Map-Reply

	The integrity of the EID-AD is verified using the locally stored ITR-	The integrity of the EID-AD is verified using the locally stored ITR-
	OTK to re-compute the HMAC of the EID-AD using the algorithm	OTK to re-compute the HMAC of the EID-AD using the algorithm
	specified in the EID HMAC ID field. If the EID HMAC ID field does	specified in the EID HMAC ID field. If the EID HMAC ID field does
	not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply	not match the Requested HMAC ID the ITR SHOULD discard the Map-Reply
	and send, at the first opportunity it needs to, a new Map-Request	and send, at the first opportunity it needs to, a new Map-Request
	with a different Requested HMAC ID field, according to ITR's local	with a different Requested HMAC ID field, according to ITR's local
	policy. The scope of the HMAC operation covers the entire EID-AD,	policy. 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	from the EID-AD Length field to the EID HMAC field, which must be set
	to 0 before the computation of the HMAC.	to 0 before the computation of the HMAC.

	skipping to change at page 18, line 26 ¶	skipping to change at page 18, line 26 ¶

	As an example at the other end of the spectrum, in certain other	As an example at the other end of the spectrum, in certain other
	deployments, attackers may be very sophisticated, and force the	deployments, attackers may be very sophisticated, and force the
	deployers to enforce very strict policies in term of HMAC algorithms	deployers to enforce very strict policies in term of HMAC algorithms
	accepted by an ITR.	accepted by an ITR.

	Similar considerations apply to the entire LISP-SEC threat model, and	Similar considerations apply to the entire LISP-SEC threat model, and
	should guide the deployers and implementors whenever they encounter	should guide the deployers and implementors whenever they encounter
	the key word SHOULD across this memo.	the key word SHOULD across this memo.


		6.5. Provisioning of the shared keys

		Provisioning of the shared keys between the ITR and the Map-Resolver
		as well as between the ETR and the Map-Server should be performed via
		an orchestration infrastructure and it is out of the scope of this
		draft. It is recommended that both shared keys are refreshed at
		periodical intervals to address key aging or attackers gaining
		unauthorized access to the shared keys. Shared keys should be
		unpredictable random values.

		6.6. Reply Attacks

		An attacker can capture a valid Map-Request and/or Map-Reply and
		reply it, however once the ITR receives the original Map-Reply the
		<nonce,ITR-OTK> pair stored at the ITR will be discarded. If a
		replayed Map-Reply arrives at the ITR, there is no <nonce,ITR-OTK>
		that matches the incoming Map-Reply and will be discarded.

		In case of replayed Map-Request, the Map-Server, Map-Resolver and ETR
		will have to do a LISP-SEC computation. This is equivalent to a
		valid LISP-SEC computation and an attacker does not obtain any
		benefit.

	7. IANA Considerations	7. IANA Considerations

	7.1. ECM AD Type Registry	7.1. ECM AD Type Registry

	IANA is requested to create the "ECM Authentication Data Type"	IANA is requested to create the "ECM Authentication Data Type"
	registry with values 0-255, for use in the ECM LISP-SEC Extensions	registry with values 0-255, for use in the ECM LISP-SEC Extensions
	Section 5.1. The registry MUST be initially populated with the	Section 5.1. The registry MUST be initially populated with the
	following values:	following values:

	Name Value Defined In	Name Value Defined In

	skipping to change at page 20, line 43 ¶	skipping to change at page 21, line 29 ¶
	The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino	The authors would like to acknowledge Pere Monclus, Dave Meyer, Dino
	Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt	Farinacci, Brian Weis, David McGrew, Darrel Lewis and Landon Curt
	Noll for their valuable suggestions provided during the preparation	Noll for their valuable suggestions provided during the preparation
	of this document.	of this document.

	9. Normative References	9. Normative References

	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,	Hashing for Message Authentication", RFC 2104,
	DOI 10.17487/RFC2104, February 1997,	DOI 10.17487/RFC2104, February 1997,

	<http://www.rfc-editor.org/info/rfc2104>.	<https://www.rfc-editor.org/info/rfc2104>.

	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,	DOI 10.17487/RFC2119, March 1997,

	<http://www.rfc-editor.org/info/rfc2119>.	<https://www.rfc-editor.org/info/rfc2119>.

	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard	[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,	(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,

	September 2002, <http://www.rfc-editor.org/info/rfc3394>.	September 2002, <https://www.rfc-editor.org/info/rfc3394>.

	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,	"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,	DOI 10.17487/RFC4086, June 2005,

	<http://www.rfc-editor.org/info/rfc4086>.	<https://www.rfc-editor.org/info/rfc4086>.

	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an

	IANA Considerations Section in RFCs", BCP 26, RFC 5226,	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,	DOI 10.17487/RFC5226, May 2008,

	<http://www.rfc-editor.org/info/rfc5226>.	<https://www.rfc-editor.org/info/rfc5226>.

	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand	[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
	Key Derivation Function (HKDF)", RFC 5869,	Key Derivation Function (HKDF)", RFC 5869,
	DOI 10.17487/RFC5869, May 2010,	DOI 10.17487/RFC5869, May 2010,

	<http://www.rfc-editor.org/info/rfc5869>.	<https://www.rfc-editor.org/info/rfc5869>.

	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms	[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
	(SHA and SHA-based HMAC and HKDF)", RFC 6234,	(SHA and SHA-based HMAC and HKDF)", RFC 6234,
	DOI 10.17487/RFC6234, May 2011,	DOI 10.17487/RFC6234, May 2011,

	<http://www.rfc-editor.org/info/rfc6234>.	<https://www.rfc-editor.org/info/rfc6234>.

	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The	[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
	Locator/ID Separation Protocol (LISP)", RFC 6830,	Locator/ID Separation Protocol (LISP)", RFC 6830,
	DOI 10.17487/RFC6830, January 2013,	DOI 10.17487/RFC6830, January 2013,

	<http://www.rfc-editor.org/info/rfc6830>.	<https://www.rfc-editor.org/info/rfc6830>.

	[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation	[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
	Protocol (LISP) Map-Server Interface", RFC 6833,	Protocol (LISP) Map-Server Interface", RFC 6833,
	DOI 10.17487/RFC6833, January 2013,	DOI 10.17487/RFC6833, January 2013,

	<http://www.rfc-editor.org/info/rfc6833>.	<https://www.rfc-editor.org/info/rfc6833>.

	[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,	[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol Alternative Logical	"Locator/ID Separation Protocol Alternative Logical
	Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,	Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,

	January 2013, <http://www.rfc-editor.org/info/rfc6836>.	January 2013, <https://www.rfc-editor.org/info/rfc6836>.

	[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID	[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
	Separation Protocol (LISP) Threat Analysis", RFC 7835,	Separation Protocol (LISP) Threat Analysis", RFC 7835,
	DOI 10.17487/RFC7835, April 2016,	DOI 10.17487/RFC7835, April 2016,

	<http://www.rfc-editor.org/info/rfc7835>.	<https://www.rfc-editor.org/info/rfc7835>.

	Authors' Addresses	Authors' Addresses

	Fabio Maino	Fabio Maino
	Cisco Systems	Cisco Systems
	170 Tasman Drive	170 Tasman Drive
	San Jose, California 95134	San Jose, California 95134
	USA	USA

	Email: fmaino@cisco.com	Email: fmaino@cisco.com

	skipping to change at page 22, line 22 ¶	skipping to change at page 23, line 4 ¶

	Email: fmaino@cisco.com	Email: fmaino@cisco.com

	Vina Ermagan	Vina Ermagan
	Cisco Systems	Cisco Systems
	170 Tasman Drive	170 Tasman Drive
	San Jose, California 95134	San Jose, California 95134
	USA	USA

	Email: vermagan@cisco.com	Email: vermagan@cisco.com


	Albert Cabellos	Albert Cabellos

	Technical University of Catalonia	Universitat Politecnica de Catalunya
	c/ Jordi Girona s/n	c/ Jordi Girona s/n
	Barcelona 08034	Barcelona 08034
	Spain	Spain

	Email: acabello@ac.upc.edu	Email: acabello@ac.upc.edu

	Damien Saucez	Damien Saucez
	INRIA	INRIA
	2004 route des Lucioles - BP 93	2004 route des Lucioles - BP 93
	Sophia Antipolis	Sophia Antipolis

End of changes. 26 change blocks.
	29 lines changed or deleted	54 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/