draft-ietf-babel-hmac-02.txt		draft-ietf-babel-hmac-03.txt
	Network Working Group C. Do		Network Working Group C. Do
	Internet-Draft W. Kolodziejak		Internet-Draft W. Kolodziejak
	Obsoletes: 7298 (if approved) J. Chroboczek		Obsoletes: 7298 (if approved) J. Chroboczek
	Updates: 6126bis (if approved) IRIF, University of Paris-Diderot		Updates: 6126bis (if approved) IRIF, University of Paris-Diderot
	Intended status: Standards Track December 23, 2018		Intended status: Standards Track December 26, 2018
	Expires: June 26, 2019		Expires: June 29, 2019
	HMAC authentication for the Babel routing protocol		HMAC authentication for the Babel routing protocol
	draft-ietf-babel-hmac-02		draft-ietf-babel-hmac-03
	Abstract		Abstract
	This document describes a cryptographic authentication for the Babel		This document describes a cryptographic authentication mechanism for
	routing protocol that has provisions for replay avoidance. This		the Babel routing protocol that has provisions for replay avoidance.
	document updates RFC 6126bis and obsoletes RFC 7298.		This document updates RFC 6126bis and obsoletes RFC 7298.
	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 https://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 June 26, 2019.		This Internet-Draft will expire on June 29, 2019.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 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
	(https://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
	skipping to change at page 2, line 34 ¶		skipping to change at page 2, line 34 ¶
	5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12		5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . 14
	9.2. Informational References . . . . . . . . . . . . . . . . 15		9.2. Informational References . . . . . . . . . . . . . . . . 15
	Appendix A. Incremental deployment and key rotation . . . . . . 15		Appendix A. Incremental deployment and key rotation . . . . . . 15
	Appendix B. Changes from previous versions . . . . . . . . . . . 16		Appendix B. Changes from previous versions . . . . . . . . . . . 16
	B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16		B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16
	B.2. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16		B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16		B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 16
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	By default, the Babel routing protocol trusts the information		By default, the Babel routing protocol trusts the information
	contained in every UDP packet it receives on the Babel port. An		contained in every UDP packet it receives on the Babel port. An
	attacker can redirect traffic to itself or to a different node in the		attacker can redirect traffic to itself or to a different node in the
	network, causing a variety of potential issues. In particular, an		network, causing a variety of potential issues. In particular, an
	attacker might:		attacker might:
	o spoof a Babel packet, and redirect traffic by announcing a smaller		o spoof a Babel packet, and redirect traffic by announcing a smaller
	skipping to change at page 3, line 51 ¶		skipping to change at page 3, line 51 ¶
	o that the Hashed Message Authentication Code (HMAC) being used is		o that the Hashed Message Authentication Code (HMAC) being used is
	invulnerable to pre-image attacks, i.e., that an attacker is		invulnerable to pre-image attacks, i.e., that an attacker is
	unable to generate a packet with a correct HMAC;		unable to generate a packet with a correct HMAC;
	o that a node never generates the same index or nonce twice over the		o that a node never generates the same index or nonce twice over the
	lifetime of a key.		lifetime of a key.
	The first assumption is a property of the HMAC being used. The		The first assumption is a property of the HMAC being used. The
	second assumption can be met either by using a robust random number		second assumption can be met either by using a robust random number
	generator and sufficiently large indices and nonces, by using a		generator [RFC4086] and sufficiently large indices and nonces, by
	reliable hardware clock, or by rekeying whenever a collision becomes		using a reliable hardware clock, or by rekeying whenever a collision
	likely.		becomes likely.
	If the assumptions above are met, the protocol described in this		If the assumptions above are met, the protocol described in this
	document has the following properties:		document has the following properties:
	o it is invulnerable to spoofing: any packet accepted as authentic		o it is invulnerable to spoofing: any packet accepted as authentic
	is the exact copy of a packet originally sent by an authorised		is the exact copy of a packet originally sent by an authorised
	node;		node;
	o locally to a single node, it is invulnerable to replay: if a node		o locally to a single node, it is invulnerable to replay: if a node
	has previously accepted a given packet, then it will never again		has previously accepted a given packet, then it will never again
	skipping to change at page 7, line 47 ¶		skipping to change at page 7, line 47 ¶
	interface MTU (Section 4 of [RFC6126bis]). For an interface on which		interface MTU (Section 4 of [RFC6126bis]). For an interface on which
	HMAC protection is configured, the TLV aggregation logic MUST take		HMAC protection is configured, the TLV aggregation logic MUST take
	into account the overhead due to PC TLVs (one in each packet) and		into account the overhead due to PC TLVs (one in each packet) and
	HMAC TLVs (one per configured key).		HMAC TLVs (one per configured key).
	Before sending a packet, the following actions are performed:		Before sending a packet, the following actions are performed:
	o a PC TLV containing the PC and Index associated with the outgoing		o a PC TLV containing the PC and Index associated with the outgoing
	interface is appended to the packet body; the PC is incremented by		interface is appended to the packet body; the PC is incremented by
	a strictly positive amount (typically just 1); if the PC		a strictly positive amount (typically just 1); if the PC
	overflows, a new index is generated;		overflows, a fresh index is generated;
	o for each key configured on the interface, an HMAC is computed as		o for each key configured on the interface, an HMAC is computed as
	specified in Section 4.1 above, and an HMAC TLV is appended to the		specified in Section 4.1 above, and an HMAC TLV is appended to the
	packet trailer (see Section 4.2 of [RFC6126bis]).		packet trailer (see Section 4.2 of [RFC6126bis]).
	4.3. Packet Reception		4.3. Packet Reception
	When a packet is received on an interface that is configured for HMAC		When a packet is received on an interface that is configured for HMAC
	protection, the following steps are performed before the packet is		protection, the following steps are performed before the packet is
	passed to normal processing:		passed to normal processing:
	skipping to change at page 10, line 50 ¶		skipping to change at page 10, line 50 ¶
	table, and is normally discarded when the neighbour table entry		table, and is normally discarded when the neighbour table entry
	expires. Implementations MUST ensure that an (Index, PC) pair is		expires. Implementations MUST ensure that an (Index, PC) pair is
	discarded within a finite time since the last time a packet has been		discarded within a finite time since the last time a packet has been
	accepted. In particular, unsuccessful challenges MUST NOT prevent an		accepted. In particular, unsuccessful challenges MUST NOT prevent an
	(Index, PC) pair from being discarded for unbounded periods of time.		(Index, PC) pair from being discarded for unbounded periods of time.
	Implementations that use a Hello history (Appendix A of [RFC6126bis])		Implementations that use a Hello history (Appendix A of [RFC6126bis])
	may discard the (Index, PC) pair whenever the Hello history becomes		may discard the (Index, PC) pair whenever the Hello history becomes
	empty. Other impementations may use a timer that is reset whenever a		empty. Other impementations may use a timer that is reset whenever a
	packet is accepted, and discard the (Index, PC) pair whenever the		packet is accepted, and discard the (Index, PC) pair whenever the
	timer expires (an timeout of 5 min is suggested).		timer expires (a timeout of 5 min is suggested).
	5. Packet Format		5. Packet Format
	5.1. HMAC TLV		5.1. HMAC TLV
	0 1 2 3		0 1 2 3
	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		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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | HMAC...		| Type | Length | HMAC...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	skipping to change at page 11, line 46 ¶		skipping to change at page 11, line 46 ¶
	| Index...		| Index...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	Fields :		Fields :
	Type Set to TBD to indicate a PC TLV.		Type Set to TBD to indicate a PC TLV.
	Length The length of the body, exclusive of the Type and Length		Length The length of the body, exclusive of the Type and Length
	fields.		fields.
	PC The Packet Counter (PC), which is increased with every		PC The Packet Counter (PC), a 32-bit (4 octet) unsigned
	packet sent over this interface. A new index MUST be		integer which is increased with every packet sent over this
	generated whenever the PC overflows.		interface. A fresh index MUST be generated whenever the PC
			overflows.
	Index The sender's Index.		Index The sender's Index, an opaque string of 0 to 32 octets.
	Indices are limited to a size of 32 octets: a node MUST NOT send a		Indices are limited to a size of 32 octets: a node MUST NOT send a
	TLV with an index of size strictly larger than 32 octets, and a node		TLV with an index of size strictly larger than 32 octets, and a node
	MAY silently ignore a PC TLV with an index of size strictly larger		MAY silently ignore a PC TLV with an index of size strictly larger
	than 32 octets.		than 32 octets.
	5.3. Challenge Request TLV		5.3. Challenge Request TLV
	0 1 2 3		0 1 2 3
	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		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
	skipping to change at page 12, line 25 ¶		skipping to change at page 12, line 25 ¶
	| Type | Length | Nonce...		| Type | Length | Nonce...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
	Fields :		Fields :
	Type Set to TBD to indicate a Challenge Request TLV.		Type Set to TBD to indicate a Challenge Request TLV.
	Length The length of the body, exclusive of the Type and Length		Length The length of the body, exclusive of the Type and Length
	fields.		fields.
	Nonce The nonce uniquely identifying the challenge.		Nonce The nonce uniquely identifying the challenge, an opaque
			string of 0 to 192 octets.
	Nonces are limited to a size of 192 octets: a node MUST NOT send a		Nonces are limited to a size of 192 octets: a node MUST NOT send a
	Challenge Request TLV with a nonce of size strictly larger than 192		Challenge Request TLV with a nonce of size strictly larger than 192
	octets, and a node MAY ignore a nonce that is of size strictly larger		octets, and a node MAY ignore a nonce that is of size strictly larger
	than 192 octets.		than 192 octets.
	5.4. Challenge Reply TLV		5.4. Challenge Reply TLV
	0 1 2 3		0 1 2 3
	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		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
	skipping to change at page 13, line 31 ¶		skipping to change at page 13, line 31 ¶
	(Section 4.1), is believed to be safe against practical attacks.		(Section 4.1), is believed to be safe against practical attacks.
	Second, it assumes that indices and nonces are generated uniquely		Second, it assumes that indices and nonces are generated uniquely
	over the lifetime of a key used for HMAC computation (more precisely,		over the lifetime of a key used for HMAC computation (more precisely,
	indices must be unique for a given (key, source) pair, and nonces		indices must be unique for a given (key, source) pair, and nonces
	must be unique for a given (key, source, destination) triple). This		must be unique for a given (key, source, destination) triple). This
	property can be satisfied either by using a cryptographically secure		property can be satisfied either by using a cryptographically secure
	random number generator to generate indices and nonces that contain		random number generator to generate indices and nonces that contain
	enough entropy (64-bit values are believed to be large enough for all		enough entropy (64-bit values are believed to be large enough for all
	practical applications), or by using a reliably monotonic hardware		practical applications), or by using a reliably monotonic hardware
	clock. If unicity cannot be guaranteed (e.g., because a hardware		clock. If uniqueness cannot be guaranteed (e.g., because a hardware
	clock has been reset), then rekeying is necessary.		clock has been reset), then rekeying is necessary.
	The expiry mechanism mandated in Section 4.4 is required to prevent		The expiry mechanism mandated in Section 4.4 is required to prevent
	an attacker from delaying an authentic packet by an unbounded amount		an attacker from delaying an authentic packet by an unbounded amount
	of time. If an attacker is able to delay the delivery of a packet		of time. If an attacker is able to delay the delivery of a packet
	(e.g., because it is located at a layer 2 switch), then the packet		(e.g., because it is located at a layer 2 switch), then the packet
	will be accepted as long as the corresponding (Index, PC) pair is		will be accepted as long as the corresponding (Index, PC) pair is
	present at the receiver. If the attacker is able to cause the		present at the receiver. If the attacker is able to cause the
	(Index, PC) pair to persist for arbitrary amounts of time (e.g., by		(Index, PC) pair to persist for arbitrary amounts of time (e.g., by
	causing failed challenges), then it is able to delay the packet by		causing failed challenges), then it is able to delay the packet by
	skipping to change at page 14, line 14 ¶		skipping to change at page 14, line 14 ¶
	At first sight, sending a challenge requires retaining enough		At first sight, sending a challenge requires retaining enough
	information to validate the challenge reply. However, the nonce		information to validate the challenge reply. However, the nonce
	included in a challenge request and echoed in the challenge reply can		included in a challenge request and echoed in the challenge reply can
	be fairly large (up to 192 octets), which should in principle permit		be fairly large (up to 192 octets), which should in principle permit
	encoding the per-challenge state as a secure "cookie" within the		encoding the per-challenge state as a secure "cookie" within the
	nonce itself.		nonce itself.
	7. IANA Considerations		7. IANA Considerations
	IANA is instructed to allocate the following values in the Babel TLV		IANA is requested to allocate the following values in the Babel TLV
	Numbers registry:		Numbers registry:
	+------+-------------------+---------------+		+------+-------------------+---------------+
	| Type | Name | Reference |		| Type | Name | Reference |
	+------+-------------------+---------------+		+------+-------------------+---------------+
	| TBD | HMAC | this document |		| TBD | HMAC | this document |
	| | | |		| | | |
	| TBD | PC | this document |		| TBD | PC | this document |
	| | | |		| | | |
	| TBD | Challenge Request | this document |		| TBD | Challenge Request | this document |
	skipping to change at page 15, line 31 ¶		skipping to change at page 15, line 31 ¶
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017.		May 2017.
	9.2. Informational References		9.2. Informational References
	[I-D.ietf-babel-dtls]		[I-D.ietf-babel-dtls]
	Decimo, A., Schinazi, D., and J. Chroboczek, "Babel		Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
	Routing Protocol over Datagram Transport Layer Security",		Routing Protocol over Datagram Transport Layer Security",
	draft-ietf-babel-dtls-01 (work in progress), October 2018.		draft-ietf-babel-dtls-01 (work in progress), October 2018.
			[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
			"Randomness Requirements for Security", BCP 106, RFC 4086,
			DOI 10.17487/RFC4086, June 2005,
			<http://www.rfc-editor.org/info/rfc4086>.
	[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues		[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
	with Existing Cryptographic Protection Methods for Routing		with Existing Cryptographic Protection Methods for Routing
	Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,		Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
	<https://www.rfc-editor.org/info/rfc6039>.		<https://www.rfc-editor.org/info/rfc6039>.
	[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code		[RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code
	(HMAC) Cryptographic Authentication", RFC 7298,		(HMAC) Cryptographic Authentication", RFC 7298,
	DOI 10.17487/RFC7298, July 2014,		DOI 10.17487/RFC7298, July 2014,
	<https://www.rfc-editor.org/info/rfc7298>.		<https://www.rfc-editor.org/info/rfc7298>.
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 37 ¶
	o Removed the appendix about the packet trailer, this is now in		o Removed the appendix about the packet trailer, this is now in
	rfc6126bis.		rfc6126bis.
	o Removed the appendix with implicit indices.		o Removed the appendix with implicit indices.
	o Clarified the definitions of acronyms.		o Clarified the definitions of acronyms.
	o Limited the size of nonces and indices.		o Limited the size of nonces and indices.
	B.2. Changes since draft-ietf-babel-hmac-00		B.2. Changes since draft-ietf-babel-hmac-01
	o Made BLAKE2s a recommended HMAC algorithm.		o Made BLAKE2s a recommended HMAC algorithm.
	o Added requirement to expire per-neighbour crypto state.		o Added requirement to expire per-neighbour crypto state.
			B.3. Changes since draft-ietf-babel-hmac-02
			o Clarified that PCs are 32-bit unsigned integers.
			o Clarified that indices and nonces are of arbitrary size.
			o Added reference to RFC 4086.
	Authors' Addresses		Authors' Addresses
	Clara Do		Clara Do
	IRIF, University of Paris-Diderot		IRIF, University of Paris-Diderot
	75205 Paris Cedex 13		75205 Paris Cedex 13
	France		France
	Email: clarado_perso@yahoo.fr		Email: clarado_perso@yahoo.fr
	Weronika Kolodziejak		Weronika Kolodziejak
End of changes. 16 change blocks.
	22 lines changed or deleted		38 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/