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/