draft-ietf-babel-hmac-00.txt   draft-ietf-babel-hmac-01.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 August 16, 2018 Intended status: Standards Track November 14, 2018
Expires: February 17, 2019 Expires: May 18, 2019
Babel Cryptographic Authentification HMAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-00 draft-ietf-babel-hmac-01
Abstract Abstract
This document describes a cryptographic authentication mechanism for This document describes a cryptographic authentication for the Babel
the Babel routing protocol that has provisions for replay avoidance. routing protocol that has provisions for replay avoidance. This
This document updates RFC 6126bis and obsoletes RFC 7298. 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 February 17, 2019. This Internet-Draft will expire on May 18, 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 18 skipping to change at page 2, line 18
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Assumptions and security properties . . . . . . . . . . . 3 1.2. Assumptions and security properties . . . . . . . . . . . 3
1.3. Specification of Requirements . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . 4
2. Conceptual overview of the protocol . . . . . . . . . . . . . 4 2. Conceptual overview of the protocol . . . . . . . . . . . . . 4
3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 5 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 5
3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 6
4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 6
4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 7
4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 7 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 11 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 11
5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 11 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informational References . . . . . . . . . . . . . . . . 13 9.2. Informational References . . . . . . . . . . . . . . . . 14
Appendix A. Use of the packet trailer . . . . . . . . . . . . . 13 Appendix A. Incremental deployment and key rotation . . . . . . 15
Appendix B. Incremental deployment and key rotation . . . . . . 13 Appendix B. Changes from previous versions . . . . . . . . . . . 15
Appendix C. Implicit indices . . . . . . . . . . . . . . . . . . 14 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 7 skipping to change at page 3, line 7
o spoof a malformed packet, which could cause an insufficiently o spoof a malformed packet, which could cause an insufficiently
robust implementation to crash or interfere with the rest of the robust implementation to crash or interfere with the rest of the
network; network;
o replay a previously captured Babel packet, which could cause o replay a previously captured Babel packet, which could cause
traffic to be redirected or otherwise interfere with the network. traffic to be redirected or otherwise interfere with the network.
Protecting a Babel network is challenging due to the fact that the Protecting a Babel network is challenging due to the fact that the
Babel protocol uses both unicast and multicast communication. One Babel protocol uses both unicast and multicast communication. One
possible approach, used notably by the Babel over DTLS protocol, is possible approach, used notably by the Babel over Datagram Transport
to require a secured version of Babel to use unicast communication Layer Security (DTLS) protocol [I-D.ietf-babel-dtls], is to use
for all semantically significant communication, and then use a unicast communication for all semantically significant communication,
standard unicast security protocol to protect the Babel traffic. In and then use a standard unicast security protocol to protect the
this document, we take the opposite approach: we define a Babel traffic. In this document, we take the opposite approach: we
cryptographic extension to the Babel protocol that is able to protect define a cryptographic extension to the Babel protocol that is able
both unicast and multicast traffic, and thus requires very few to protect both unicast and multicast traffic, and thus requires very
changes to the core protocol. few changes to the core protocol.
1.1. Applicability 1.1. Applicability
The protocol defined in this document assumes that all interfaces on The protocol defined in this document assumes that all interfaces on
a given link are equally trusted and share a small set of symmetric a given link are equally trusted and share a small set of symmetric
keys (usually just one, two during key rotation). The protocol is keys (usually just one, and two during key rotation). The protocol
inapplicable in situations where asymmetric keying is required, where is inapplicable in situations where asymmetric keying is required,
the trust relationship is partial, or where large numbers of trusted where the trust relationship is partial, or where large numbers of
keys are provisioned on a single link at the same time. trusted keys are provisioned on a single link at the same time.
This protocol supports incremental deployment (where an insecure This protocol supports incremental deployment (where an insecure
Babel network is made secure with no service interruption), and it Babel network is made secure with no service interruption), and it
supports graceful key rotation (where the set of keys is changed with supports graceful key rotation (where the set of keys is changed with
no service interruption). no service interruption).
This protocol does not require synchronised clocks, it does not This protocol does not require synchronised clocks, it does not
require persistently monotonic clocks, and it does not require any require persistently monotonic clocks, and it does not require any
form of persistent storage. form of persistent storage.
1.2. Assumptions and security properties 1.2. Assumptions and security properties
The correctness of the protocol relies on the following assumptions: The correctness of the protocol relies on the following assumptions:
o that the HMAC being used is invulnerable to spoofing, i.e. that an o that the Hashed Message Authentication Code (HMAC) being used is
attacker is unable to generate a packet with a correct HMAC; invulnerable to pre-image attacks, i.e., that an attacker is
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, and is The first assumption is a property of the HMAC being used. The
therefore out-of-scope for this document. The second assumption can second assumption can be met either by using a robust random number
be met either by using a robust random number generator and generator and sufficiently large indices and nonces, by using a
sufficiently large indices and nonces, by using a reliable hardware reliable hardware clock, or by rekeying whenever a collision becomes
clock, or by rekeying whenever a collision becomes likely. 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 5, line 36 skipping to change at page 5, line 36
A. A.
Another mechanism is needed to protect against this attack. In this Another mechanism is needed to protect against this attack. In this
protocol, every PC is tagged with an "index", an arbitrary string of protocol, every PC is tagged with an "index", an arbitrary string of
octets. Whenever B resets its PC, or whenever B doesn't know whether octets. Whenever B resets its PC, or whenever B doesn't know whether
its PC has been reset, it picks an index that it has never used its PC has been reset, it picks an index that it has never used
before (either by drawing it randomly or by using a reliable hardware before (either by drawing it randomly or by using a reliable hardware
clock) and starts sending PCs with that index. Whenever A detects clock) and starts sending PCs with that index. Whenever A detects
that B has changed its index, it challenges B again. that B has changed its index, it challenges B again.
With this additional mechanism, this protocol is provably With this additional mechanism, this protocol is invulnerable to
invulnerable to replay attacks (see Section 1.2 above). replay attacks (see Section 1.2 above).
3. Data Structures 3. Data Structures
3.1. The Interface Table 3.1. The Interface Table
Every Babel node maintains an interface table, as described in Every Babel node maintains an interface table, as described in
[RFC6126bis] Section 3.2.3. This protocol extends the entries in [RFC6126bis] Section 3.2.3. This protocol extends the entries in
this table with a set of HMAC keys, and a pair (Index, PC), where this table with a set of HMAC keys, and a pair (Index, PC), where
Index is an arbitrary string of bytes and PC is a 32-bit integer. Index is an arbitrary string of bytes and PC is a 32-bit integer.
The Index is initialised to a value that has never been used before The Index is initialised to a value that has never been used before
skipping to change at page 6, line 22 skipping to change at page 6, line 22
The Nonce and expiry timer are initially undefined and used as The Nonce and expiry timer are initially undefined and used as
described in Section 4.3.1.1. described in Section 4.3.1.1.
4. Protocol Operation 4. Protocol Operation
4.1. HMAC computation 4.1. HMAC computation
A Babel node computes an HMAC as follows. A Babel node computes an HMAC as follows.
First, the node builds a pseudo-header that will participate in HMAC First, the node builds a pseudo-header that will participate in HMAC
computation but will not be sent. The pseudo-header has the computation but will not be sent. If the packet was carried over
following format: IPv6, the pseudo-header has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Src address + + Src address +
| | | |
+ + + +
skipping to change at page 6, line 47 skipping to change at page 6, line 47
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
+ + + +
| Dest address | | Dest address |
+ + + +
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Dest port | | | Dest port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
If the packet was carried over IPv4, the pseudo-header has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src port | Dest address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Dest port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields : Fields :
Src address The source IP address of the packet. Src address The source IP address of the packet.
Src port The source UDP port number of the packet. Src port The source UDP port number of the packet.
Dest address The destination IP address of the packet. Dest address The destination IP address of the packet.
Src port The destination UDP port number of the packet. Src port The destination UDP port number of the packet.
skipping to change at page 7, line 27 skipping to change at page 7, line 43
A Babel node may delay actually sending TLVs by a small amount, in A Babel node may delay actually sending TLVs by a small amount, in
order to aggregate multiple TLVs in a single packet up to the order to aggregate multiple TLVs in a single packet up to the
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 Packet Counter and Index associated with o a PC TLV containing the PC and Index associated with the outgoing
the outgoing interface is appended to the packet body; the packet interface is appended to the packet body; the PC is incremented by
counter is incremented by a strictly positive amount (typically a strictly positive amount (typically just 1); if the PC
just 1); if the packet counter overflows, a new index is overflows, a new index is generated;
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. 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:
o First, the receiver checks whether the trailer of the received o First, the receiver checks whether the trailer of the received
packet carries at least one HMAC TLV; if not, the packet is packet carries at least one HMAC TLV; if not, the packet is
immediately dropped and processing stops. Then, for each key immediately dropped and processing stops. Then, for each key
skipping to change at page 10, line 33 skipping to change at page 10, line 49
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to TBD to indicate an HMAC TLV Type Set to TBD to indicate an HMAC 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. The length of the body depends on the hash fields. The length of the body depends on the hash
function used. function used.
HMAC The body contains the HMAC of the whole packet plus the HMAC The body contains the HMAC of the whole packet plus the
pseudo header. pseudo header.
This TLV is allowed in the packet trailer (see Appendix A), and MUST This TLV is allowed in the packet trailer (see Section 4.2 of
BE ignored if it is found in the packet body. [RFC6126bis]), and MUST be ignored if it is found in the packet body.
5.2. PC TLV 5.2. PC 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 | PC | Type | Length | PC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index... | Index...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
skipping to change at page 11, line 14 skipping to change at page 11, line 27
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 | PC | Type | Length | PC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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), which is increased with every
packet sent over this interface. A new index MUST be packet sent over this interface. A new index MUST be
generated whenever the PC overflows. generated whenever the PC overflows.
Index The sender's Index. Index The sender's Index.
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
MAY silently ignore a PC TLV with an index of size strictly larger
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
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
octets, and a node MAY ignore a nonce that is of size strictly larger
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Nonce... | Type | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to TBD to indicate a Challenge Reply TLV Type Set to TBD to indicate a Challenge Reply 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. The length of the body is set to the same size as fields. The length of the body is set to the same size as
the challenge request TLV length received. the challenge request TLV length received.
Nonce A copy of the nonce contained in the corresponding Nonce A copy of the nonce contained in the corresponding
challenge request. challenge request.
6. Security Considerations 6. Security Considerations
This document defines a mechanism that provides basic security
properties for the Babel routing protocol. The scope of this
protocol is strictly limited: it only provides authentication, on the
assumption that routing information is not confidential, only
symmetric keying, and only allows for the use of a small number of
symmetric keys on each link. Deployments that need more features,
e.g., confidentiality or asymmetric keying, should use a more
featureful security mechanism such as the one described in
[I-D.ietf-babel-dtls].
This mechanism relies on two assumptions, as described in
Section 1.2. First, it assumes that the hash being used is
invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the
time of writing, SHA-256, which is mandatory to implement
(Section 4.1), is believed to be safe against practical attacks.
Second, it assumes that indices and nonces are generated uniquely
over the lifetime of a key used for HMAC computation. This property
can be satisfied either by using a cryptographically secure random
number generator to generate indices and nonces that contain enough
entropy (64-bit values are believed to be large enough for all
practical applications), or by using a reliably monotonic hardware
clock. If unicity cannot be guaranteed (e.g., because a hardware
clock has been reset), then rekeying is necessary.
While it is probably not possible to be immune against denial of
service (DoS) attacks in general, this protocol includes a number of
mechanisms designed to mitigate such attacks. In particular,
reception of a packet with no correct HMAC creates no local state
whatsoever (Section 4.3). Reception of a replayed packet with
correct hash, on the other hand, causes a challenge to be sent; this
is mitigated somewhat by requiring that challenges be rate-limited.
At first sight, sending a challenge requires retaining enough
information to validate the challenge reply. However, the nonce
included in a challenge request and echoed in the challenge reply can
be fairly large (up to 192 octets), which should in principle permit
encoding the per-challenge state as a secure "cookie" within the
nonce itself.
7. IANA Considerations 7. IANA Considerations
IANA is instructed to allocate the following values in the Babel TLV IANA is instructed 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 |
| | | | | | | |
skipping to change at page 13, line 5 skipping to change at page 14, line 18
[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,
<https://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.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
<https://www.rfc-editor.org/info/rfc6039>.
[RFC6126bis] [RFC6126bis]
Chroboczek, J. and D. Schinazi, "The Babel Routing Chroboczek, J. and D. Schinazi, "The Babel Routing
Protocol", draft-ietf-babel-rfc6126bis-05 (work in Protocol", draft-ietf-babel-rfc6126bis-06 (work in
progress), May 2018. progress), October 2018.
[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,
<https://www.rfc-editor.org/info/rfc6234>. <https://www.rfc-editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
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]
Decimo, A., Schinazi, D., and J. Chroboczek, "Babel
Routing Protocol over Datagram Transport Layer Security",
draft-ietf-babel-dtls-01 (work in progress), October 2018.
[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>.
Appendix A. Use of the packet trailer Appendix A. Incremental deployment and key rotation
The protocol described in this document uses the packet trailer for
storing HMAC TLVs. RFC 6126bis [RFC6126bis] leaves the format of the
packet trailer undefined. If the final version of this specification
uses the packet trailer, RFC 6126bis will need to be extended with
information about the format of the packet trailer.
This document assumes that the packet trailer has the same format as
the packet body, i.e., that it consists of a sequence of TLVs. The
receiver MUST silently ignore any TLV found in the packet trailer
unless its definition states that the TLV is allowed in the packet
trailer.
Appendix B. Incremental deployment and key rotation
This protocol supports incremental deployment (transitioning from an This protocol supports incremental deployment (transitioning from an
insecure network to a secured network with no service interruption) insecure network to a secured network with no service interruption)
and key rotation (transitioning from a set of keys to a different set and key rotation (transitioning from a set of keys to a different set
of keys). of keys).
In order to perform incremental deployment, the nodes in the network In order to perform incremental deployment, the nodes in the network
are first configured in a mode where packets are sent with are first configured in a mode where packets are sent with
authentication but not checked on reception. Once all the nodes in authentication but not checked on reception. Once all the nodes in
the network are configured to send authenticated packets, nodes are the network are configured to send authenticated packets, nodes are
skipping to change at page 14, line 16 skipping to change at page 15, line 29
nodes; once this is done, both the old and the new key are sent in nodes; once this is done, both the old and the new key are sent in
all packets, and packets are accepted if they are properly signed by all packets, and packets are accepted if they are properly signed by
either of the keys. At that point, the old key is removed. either of the keys. At that point, the old key is removed.
In order to support incremental deployment and key rotation, In order to support incremental deployment and key rotation,
implementations SHOULD support an interface configuration in which implementations SHOULD support an interface configuration in which
they send authenticated packets but accept all packets, and SHOULD they send authenticated packets but accept all packets, and SHOULD
allow changing the set of keys associated with an interface without a allow changing the set of keys associated with an interface without a
restart. restart.
Appendix C. Implicit indices Appendix B. Changes from previous versions
[This appendix describes the "implicit indices" variant of the
protocol, which is different and incompatible to the "explicit
indices" variant described in the body of this document. This
section should either be integrated into the body of the document or
removed before publication of this document as an RFC, depending on
which protocol variant is finally chosen.]
The protocol described in the body of this document explicitly sends
indices as in each packet as part of the PC TLV. Observe that,
except when a challenge is required, the index sent on the wire is
identical to the index stored in the Neighbour Table, and therefore
doesn't need to be sent explicitly except during challenges: it is
enough for it to participate in HMAC computation in order to protect
against replay. The "implicit indices" variant of the protocol, due
to Markus Stenberg and described in this appendix, uses this
observation to avoid sending indices explicitly and thus shaves off 2
to 16 octets from almost every packet.
The changes to the protocol are as follows. The pseudo-header
includes the Index, and therefore has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Src address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src port | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| Dest address |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Dest port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
The PC TLV no longer contains an Index, and therefore has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | PC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV is now self-terminating, and therefore allows sub-TLVs. B.1. Changes since draft-ietf-babel-hmac-00
Packets containing the Challenge Reply and Challenge Request TLVs o Changed the title.
must contain an explicit index. Two encodings are possible: one uses
Challenge Replies and Requests with an extra field for the sender's
index, which complicates the encoding somewhat but makes these two
TLVs self-terminating, the other one uses a new TLV that is used for
carrying an Index, which uses up a new TLV number but makes it
possible to reuse these two TLV with other protocols that require a
nonce-based challenge.
Packet transmission is modified as follows. If a packet contains a o Removed the appendix about the packet trailer, this is now in
Challenge or a Challenge Reply, then the node inserts its index into rfc6126bis.
the packet body. In any case, it uses its current index to generate
the pseudo-header that will be used to compute the HMAC. (This
implies that a packet must be parsed in its entirety before HMAC
validation, which requires a robust parser.)
Packet reception is modified as follows. Before checking the HMAC of o Removed the appendix with implicit indices.
a packet, the receiver checks whether the packet contains an explicit
index. If this is the case, it uses the index contained in the
packet in order to generate the pseudo header; if this is not the
case, it uses the index contained in its neighbours table. If there
is no index available for that neighbour (either because the table
doesn't contain in an entry for this neighbour, or the entry doesn't
contain an index), HMAC validation fails.
The index and PC contained in the neighbours table are only updated o Clarified the definitions of acronyms.
after HMAC validation has succeeded.
Since it is now impossible to differentiate between a failed HMAC and o Limited the size of nonces and indices.
an index change, a node must send a challenge whenever HMAC
validation fails. This implies that spoofed packets cause a spurious
challenge, but that doesn't change the security properties of the
protocol much, given that in any case replayed packets can be used to
cause a spurious challenge.
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
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: weronika.kolodziejak@gmail.com Email: weronika.kolodziejak@gmail.com
Juliusz Chroboczek Juliusz Chroboczek
IRIF, University of Paris-Diderot IRIF, University of Paris-Diderot
Case 7014 Case 7014
75205 Paris Cedex 13 75205 Paris Cedex 13
France France
Email: jch@irif.fr Email: jch@irif.fr
 End of changes. 39 change blocks. 
161 lines changed or deleted 141 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/