draft-ietf-babel-hmac-11.txt   draft-ietf-babel-hmac-12.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
Intended status: Standards Track IRIF, University of Paris-Diderot Intended status: Standards Track IRIF, University of Paris-Diderot
Expires: February 26, 2021 August 25, 2020 Expires: March 8, 2021 September 4, 2020
MAC authentication for the Babel routing protocol MAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-11 draft-ietf-babel-hmac-12
Abstract Abstract
This document describes a cryptographic authentication mechanism for This document describes a cryptographic authentication mechanism for
the Babel routing protocol that has provisions for replay avoidance. the Babel routing protocol that has provisions for replay avoidance.
This document obsoletes RFC 7298. This document 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 26, 2021. This Internet-Draft will expire on March 8, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 3, line 51 skipping to change at page 3, line 51
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 require persistently monotonic clocks, and it does not require
persistent storage except for what might be required for storing persistent storage except for what might be required for storing
cryptographic keys. cryptographic keys.
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 Message Authentication Code (MAC) being used is o that the Message Authentication Code (MAC) being used is
invulnerable to pre-image attacks, i.e., that an attacker is invulnerable to forgery, i.e., that an attacker is unable to
unable to generate a packet with a correct MAC without access to generate a packet with a correct MAC without access to the secret
the secret key; key;
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 MAC being used. The second The first assumption is a property of the MAC being used. The second
assumption can be met either by using a robust random number assumption can be met either by using a robust random number
generator [RFC4086] and sufficiently large indices and nonces, by generator [RFC4086] and sufficiently large indices and nonces, by
using a reliable hardware clock, or by rekeying often enough that using a reliable hardware clock, or by rekeying often enough that
collisions are unlikely. collisions are unlikely.
skipping to change at page 7, line 6 skipping to change at page 7, line 6
Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in Section 3.2.4 of [RFC6126bis]. This protocol extends each entry in
this table with two new pieces of data: this table with two new pieces of data:
o a pair (Index, PC), where Index is a string of 0 to 32 octets, and o a pair (Index, PC), where Index is a string of 0 to 32 octets, and
PC is a 32-bit (4-octet) integer; PC is a 32-bit (4-octet) integer;
o a Nonce, which is an arbitrary string of 0 to 192 octets, and an o a Nonce, which is an arbitrary string of 0 to 192 octets, and an
associated challenge expiry timer. associated challenge expiry timer.
The Index and PC are initially undefined, and are managed as The Index and PC are initially undefined, and are managed as
described in Section 4.3. The Nonce and expiry timer are initially described in Section 4.3. The Nonce and challenge expiry timer are
undefined, and used as described in Section 4.3.1.1. initially undefined, and used as described in Section 4.3.1.1.
4. Protocol Operation 4. Protocol Operation
4.1. MAC computation 4.1. MAC computation
A Babel node computes the MAC of a Babel packet as follows. A Babel node computes the MAC of a Babel packet as follows.
First, the node builds a pseudo-header that will participate in MAC First, the node builds a pseudo-header that will participate in MAC
computation but will not be sent. If the packet is carried over computation but will not be sent. If the packet is carried over
IPv6, the pseudo-header has the following format: IPv6, the pseudo-header has the following format:
skipping to change at page 9, line 25 skipping to change at page 9, line 25
successfully. The MAC of the packet MUST NOT be computed for each successfully. The MAC of the packet MUST NOT be computed for each
MAC TLV contained in the packet, but only once for each configured MAC TLV contained in the packet, but only once for each configured
key. key.
o If an entry for the sender does not exist in the Neighbour Table, o If an entry for the sender does not exist in the Neighbour Table,
it MAY be created at this point (or, alternatively, its creation it MAY be created at this point (or, alternatively, its creation
can be delayed until a challenge needs to be sent, see below); can be delayed until a challenge needs to be sent, see below);
o The packet body is then parsed a first time. During this o The packet body is then parsed a first time. During this
"preparse" phase, the packet body is traversed and all TLVs are "preparse" phase, the packet body is traversed and all TLVs are
ignored except PC TLVs, Challenge Requests and Challenge Replies. ignored except PC, Challenge Request and Challenge Reply TLVs.
When a PC TLV is encountered, the enclosed PC and Index are saved When a PC TLV is encountered, the enclosed PC and Index are saved
for later processing; if multiple PCs are found (which should not for later processing; if multiple PCs are found (which should not
happen, see Section 4.2 above), only the first one is processed, happen, see Section 4.2 above), only the first one is processed,
the remaining ones MUST be silently ignored. If a Challenge the remaining ones MUST be silently ignored. If a Challenge
Request is encountered, a Challenge Reply MUST be scheduled, as Request is encountered, a Challenge Reply MUST be scheduled, as
described in Section 4.3.1.2. If a Challenge Reply is described in Section 4.3.1.2. If a Challenge Reply is
encountered, it is tested for validity as described in encountered, it is tested for validity as described in
Section 4.3.1.3 and a note is made of the result of the test. Section 4.3.1.3 and a note is made of the result of the test.
o The preparse phase above has yielded two pieces of data: the PC o The preparse phase above has yielded two pieces of data: the PC
skipping to change at page 10, line 40 skipping to change at page 10, line 40
The same is true of challenge replies. However, since validating a The same is true of challenge replies. However, since validating a
challenge reply has minimal additional cost (it's just a bitwise challenge reply has minimal additional cost (it's just a bitwise
comparison of two strings of octets), a similar optimisation for comparison of two strings of octets), a similar optimisation for
challenge replies is not worthwhile. challenge replies is not worthwhile.
After the packet has been accepted, it is processed as normal, except After the packet has been accepted, it is processed as normal, except
that any PC, Challenge Request and Challenge Reply TLVs that it that any PC, Challenge Request and Challenge Reply TLVs that it
contains are silently ignored. contains are silently ignored.
4.3.1. Challenge Requests and Replies 4.3.1. Challenge requests and replies
During the preparse stage, the receiver might encounter a mismatched During the preparse stage, the receiver might encounter a mismatched
Index, to which it will react by scheduling a Challenge Request. It Index, to which it will react by scheduling a Challenge Request. It
might encounter a Challenge Request TLV, to which it will reply with might encounter a Challenge Request TLV, to which it will reply with
a Challenge Reply TLV. Finally, it might encounter a Challenge Reply a Challenge Reply TLV. Finally, it might encounter a Challenge Reply
TLV, which it will attempt to match with a previously sent Challenge TLV, which it will attempt to match with a previously sent Challenge
Request TLV in order to update the Neighbour Table entry Request TLV in order to update the Neighbour Table entry
corresponding to the sender of the packet. corresponding to the sender of the packet.
4.3.1.1. Sending challenges 4.3.1.1. Sending challenges
skipping to change at page 11, line 41 skipping to change at page 11, line 41
cause a node to send. Second, it limits the number of challenges cause a node to send. Second, it limits the number of challenges
sent when there are multiple packets in flight from a single sent when there are multiple packets in flight from a single
neighbour. neighbour.
4.3.1.2. Replying to challenges 4.3.1.2. Replying to challenges
When it encounters a Challenge Request during the preparse phase, a When it encounters a Challenge Request during the preparse phase, a
node constructs a Challenge Reply TLV by copying the Nonce from the node constructs a Challenge Reply TLV by copying the Nonce from the
Challenge Request into the Challenge Reply. It MUST then send the Challenge Request into the Challenge Reply. It MUST then send the
Challenge Reply to the unicast address from which the Challenge Challenge Reply to the unicast address from which the Challenge
Request was sent. Request was sent. A challenge sent to a multicast address MUST be
silently ignored.
A node MAY aggregate a Challenge Reply with other TLVs; in other A node MAY aggregate a Challenge Reply with other TLVs; in other
words, if it has already buffered TLVs to be sent to the unicast words, if it has already buffered TLVs to be sent to the unicast
address of the sender of the Challenge Request, it MAY send the address of the sender of the Challenge Request, it MAY send the
buffered TLVs in the same packet as the Challenge Reply. However, it buffered TLVs in the same packet as the Challenge Reply. However, it
MUST arrange for the Challenge Reply to be sent in a timely manner MUST arrange for the Challenge Reply to be sent in a timely manner
(within a few seconds), and SHOULD NOT send any other packets over (within a few seconds), and SHOULD NOT send any other packets over
the same interface before sending the Challenge Reply, as those would the same interface before sending the Challenge Reply, as those would
be dropped by the challenger. be dropped by the challenger.
A challenge sent to a multicast address MUST be silently ignored.
Since a challenge reply might be caused by a replayed challenge Since a challenge reply might be caused by a replayed challenge
request, a node MUST impose a rate limitation to the challenge request, a node MUST impose a rate limitation to the challenge
replies it sends; the limit SHOULD default to one challenge reply for replies it sends; the limit SHOULD default to one challenge reply for
each peer every 300ms and MAY be configurable. each peer every 300ms and MAY be configurable.
4.3.1.3. Receiving challenge replies 4.3.1.3. Receiving challenge replies
When it encounters a Challenge Reply during the preparse phase, a When it encounters a Challenge Reply during the preparse phase, a
node consults the Neighbour Table entry corresponding to the node consults the Neighbour Table entry corresponding to the
neighbour that sent the Challenge Reply. If no challenge is in neighbour that sent the Challenge Reply. If no challenge is in
progress, i.e., if there is no Nonce stored in the Neighbour progress, i.e., if there is no Nonce stored in the Neighbour
Table entry or the Challenge timer has expired, the Challenge Reply Table entry or the challenge timer has expired, the Challenge Reply
MUST be silently ignored and the challenge has failed. MUST be silently ignored and the challenge has failed.
Otherwise, the node compares the Nonce contained in the Challenge Otherwise, the node compares the Nonce contained in the Challenge
Reply with the Nonce contained in the Neighbour Table entry. If the Reply with the Nonce contained in the Neighbour Table entry. If the
two are equal (they have the same length and content), then the two are equal (they have the same length and content), then the
challenge has succeeded; otherwise, the challenge has failed. challenge has succeeded and the nonce stored in the Neighbour
Table for this neighbour SHOULD be discarded; otherwise, the
challenge has failed (and the nonce is not discarded).
4.4. Expiring per-neighbour state 4.4. Expiring per-neighbour state
The per-neighbour (Index, PC) pair is maintained in the neighbour The per-neighbour (Index, PC) pair is maintained in the neighbour
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.
skipping to change at page 14, line 8 skipping to change at page 14, line 8
| | Index... | | Index...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
Type Set to 17 to indicate a PC TLV. Type Set to 17 to indicate a PC TLV.
Length The length of the body, in octets, exclusive of the Type Length The length of the body, in octets, exclusive of the Type
and Length fields. and Length fields.
PC The Packet Counter (PC), a 32-bit (4 octet) unsigned PC The Packet Counter (PC), a 32-bit (4-octet) unsigned
integer which is increased with every packet sent over this integer which is increased with every packet sent over this
interface. A fresh index (as defined in Section 3.1) MUST interface. A fresh index (as defined in Section 3.1) MUST
be generated whenever the PC overflows. be generated whenever the PC overflows.
Index The sender's Index, an opaque string of 0 to 32 octets. 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 ignore a PC TLV with an index of length strictly larger than 32 MAY ignore a PC TLV with an index of length strictly larger than 32
octets. Indices of length 0 are valid: if a node has reliable stable octets. Indices of length 0 are valid: if a node has reliable stable
skipping to change at page 15, line 34 skipping to change at page 15, line 34
protocol is strictly limited: it only provides authentication (we protocol is strictly limited: it only provides authentication (we
assume that routing information is not confidential), it only assume that routing information is not confidential), it only
supports symmetric keying, and it only allows for the use of a small supports symmetric keying, and it only allows for the use of a small
number of symmetric keys on every link. Deployments that need more number of symmetric keys on every link. Deployments that need more
features, e.g., confidentiality or asymmetric keying, should use a features, e.g., confidentiality or asymmetric keying, should use a
more featureful security mechanism such as the one described in more featureful security mechanism such as the one described in
[I-D.ietf-babel-dtls]. [I-D.ietf-babel-dtls].
This mechanism relies on two assumptions, as described in This mechanism relies on two assumptions, as described in
Section 1.2. First, it assumes that the MAC being used is Section 1.2. First, it assumes that the MAC being used is
invulnerable to pre-image attacks (Section 1.1 of [RFC6039]); at the invulnerable to forgery (Section 1.1 of [RFC6039]); at the time of
time of writing, SHA-256, which is mandatory to implement writing, HMAC-SHA256, which is mandatory to implement (Section 4.1),
(Section 4.1), is believed to be safe against practical attacks. 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 MAC computation (more precisely, over the lifetime of a key used for MAC 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 uniqueness cannot be guaranteed (e.g., because a hardware clock. If uniqueness cannot be guaranteed (e.g., because a hardware
skipping to change at page 16, line 51 skipping to change at page 16, line 51
limited by the number of distinct source addresses used with a single limited by the number of distinct source addresses used with a single
MAC key (see also Section 4 of [RFC6126bis], which mandates that the MAC key (see also Section 4 of [RFC6126bis], which mandates that the
source address is a link-local IPv6 address or a local IPv4 address). source address is a link-local IPv6 address or a local IPv4 address).
In order to make this kind of resource exhaustion attacks less In order to make this kind of resource exhaustion attacks less
effective, implementations may use a separate table of uncompleted effective, implementations may use a separate table of uncompleted
challenges that is separate from the Neighbour Table used by the core challenges that is separate from the Neighbour Table used by the core
protocol (the data structures described in Section 3.2 of protocol (the data structures described in Section 3.2 of
[RFC6126bis] are conceptual, and any data structure that yields the [RFC6126bis] are conceptual, and any data structure that yields the
same result may be used). Implementers might also consider using the same result may be used). Implementers might also consider using the
fact that the nonces included in challenge requests and responses can fact that the nonces included in challenge requests and replies can
be fairly large (up to 192 octets), which should in principle allow be fairly large (up to 192 octets), which should in principle allow
encoding the per-challenge state as a secure "cookie" within the encoding the per-challenge state as a secure "cookie" within the
nonce itself; note however that any such scheme will need to prevent nonce itself; note however that any such scheme will need to prevent
cookie replay. cookie replay.
8. IANA Considerations 8. IANA Considerations
IANA has allocated the following values in the Babel TLV Types IANA has allocated the following values in the Babel TLV Types
registry: registry:
skipping to change at page 17, line 32 skipping to change at page 17, line 32
| | | | | | | |
| 19 | Challenge Reply | this document | | 19 | Challenge Reply | this document |
+------+-------------------+---------------+ +------+-------------------+---------------+
9. Acknowledgments 9. Acknowledgments
The protocol described in this document is based on the original HMAC The protocol described in this document is based on the original HMAC
protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo- protocol defined by Denis Ovsienko [RFC7298]. The use of a pseudo-
header was suggested by David Schinazi. The use of an index to avoid header was suggested by David Schinazi. The use of an index to avoid
replay was suggested by Markus Stenberg. The authors are also replay was suggested by Markus Stenberg. The authors are also
indebted to Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn, indebted to Antonin Decimo, Donald Eastlake, Toke Hoiland-Jorgensen,
Benjamin Kaduk, Dave Taht and Martin Vigoureux. Florian Horn, Benjamin Kaduk, Dave Taht and Martin Vigoureux.
10. References 10. References
10.1. Normative References 10.1. 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,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
skipping to change at page 21, line 20 skipping to change at page 21, line 20
requests. requests.
o Added discussion of key generation. o Added discussion of key generation.
o Added discussion of the consequences of delaying packets. o Added discussion of the consequences of delaying packets.
A.8.3. Changes since draft-ietf-babel-hmac-10 A.8.3. Changes since draft-ietf-babel-hmac-10
o Fixed minor typos. o Fixed minor typos.
A.8.4. Changes since draft-ietf-babel-hmac-11
o Clarified that the state SHOULD be discarded after a successful
challenge.
o Replaced "pre-image attack" with "forgery", this is more accurate.
o Minor editorial changes.
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. 
21 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/