draft-ietf-babel-hmac-05.txt   draft-ietf-babel-hmac-06.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 Intended status: Standards Track IRIF, University of Paris-Diderot
Intended status: Standards Track June 7, 2019 Expires: December 22, 2019 June 20, 2019
Expires: December 9, 2019
HMAC authentication for the Babel routing protocol HMAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-05 draft-ietf-babel-hmac-06
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 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
skipping to change at page 1, line 34 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 December 9, 2019. This Internet-Draft will expire on December 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 19 skipping to change at page 2, line 19
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 . . . . . . . . . . . . . . . . . . . . . . . 6 3. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6 3.1. The Interface Table . . . . . . . . . . . . . . . . . . . 6
3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6 3.2. The Neighbour table . . . . . . . . . . . . . . . . . . . 6
4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7 4.1. HMAC computation . . . . . . . . . . . . . . . . . . . . 7
4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8 4.2. Packet Transmission . . . . . . . . . . . . . . . . . . . 8
4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8 4.3. Packet Reception . . . . . . . . . . . . . . . . . . . . 8
4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 11 4.4. Expiring per-neighbour state . . . . . . . . . . . . . . 12
5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12 5. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. PC TLV . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13 5.3. Challenge Request TLV . . . . . . . . . . . . . . . . . . 13
5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 13 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informational References . . . . . . . . . . . . . . . . 16 9.2. Informational References . . . . . . . . . . . . . . . . 17
Appendix A. Incremental deployment and key rotation . . . . . . 16 Appendix A. Incremental deployment and key rotation . . . . . . 17
Appendix B. Changes from previous versions . . . . . . . . . . . 17 Appendix B. Changes from previous versions . . . . . . . . . . . 18
B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 17 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 18
B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 17 B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 18
B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 17 B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 18
B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18 B.4. Changes since draft-ietf-babel-hmac-03 . . . . . . . . . 18
B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 18 B.5. Changes since draft-ietf-babel-hmac-04 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 B.6. Changes since draft-ietf-babel-hmac-05 . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
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 datagram that it receives on the Babel port. contained in every UDP datagram that it receives on the Babel port.
An attacker can redirect traffic to itself or to a different node in An attacker can redirect traffic to itself or to a different node in
the network, causing a variety of potential issues. In particular, the network, causing a variety of potential issues. In particular,
an attacker might: an 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 8, line 37 skipping to change at page 8, line 37
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 MUST be appended to the packet body; the PC MUST be interface MUST be appended to the packet body; the PC MUST be
incremented by a strictly positive amount (typically just 1); if incremented by a strictly positive amount (typically just 1); if
the PC overflows, a fresh index MUST be generated (as defined in the PC overflows, a fresh index MUST be generated (as defined in
Section 3.1); Section 3.1); a node MUST NOT include multiple PC TLVs in a single
packet;
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 stored in an HMAC TLV that specified in Section 4.1 above, and stored in an HMAC TLV that
MUST be appended to the packet trailer (see Section 4.2 of MUST be appended to the packet trailer (see Section 4.2 of
[RFC6126bis]). [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
skipping to change at page 9, line 20 skipping to change at page 9, line 23
to avoid memory exhaustion attacks, an entry in the Neighbour to avoid memory exhaustion attacks, an entry in the Neighbour
Table MUST NOT be created before the HMAC test has passed Table MUST NOT be created before the HMAC test has passed
successfully. The HMAC of the packet MUST NOT be computed for successfully. The HMAC of the packet MUST NOT be computed for
each HMAC TLV contained in the packet, but only once for each each HMAC TLV contained in the packet, but only once for each
configured key. configured key.
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 TLVs, Challenge Requests and Challenge Replies.
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, only the first for later processing; if multiple PCs are found (which should not
one is processed, the remaining ones MUST be silently ignored. If happen, see Section 4.2 above), only the first one is processed,
a Challenge Request is encountered, a Challenge Reply MUST be the remaining ones MUST be silently ignored. If a Challenge
scheduled, as described in Section 4.3.1.2. If a Challenge Reply Request is encountered, a Challenge Reply MUST be scheduled, as
is encountered, it is tested for validity as described in described in Section 4.3.1.2. If a Challenge Reply is
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
and Index from the first PC TLV, and a bit indicating whether the and Index from the first PC TLV, and a bit indicating whether the
packet contains a successful Challenge Reply. If the packet does packet contains a successful Challenge Reply. If the packet does
not contain a PC TLV, the packet MUST be dropped and processing not contain a PC TLV, the packet MUST be dropped and processing
stops at this point. If the packet contains a successful stops at this point. If the packet contains a successful
Challenge Reply, then the PC and Index contained in the PC TLV Challenge Reply, then the PC and Index contained in the PC TLV
MUST be stored in the Neighbour Table entry corresponding to the MUST be stored in the Neighbour Table entry corresponding to the
sender (which may need to be created at this stage), and the sender (which may need to be created at this stage), and the
skipping to change at page 10, line 7 skipping to change at page 10, line 10
and the Index contained in the PC TLV is equal to the Index in the and the Index contained in the PC TLV is equal to the Index in the
Neighbour Table entry corresponding to the sender. The receiver Neighbour Table entry corresponding to the sender. The receiver
compares the received PC with the PC contained in the Neighbour compares the received PC with the PC contained in the Neighbour
Table; if the received PC is smaller or equal than the PC Table; if the received PC is smaller or equal than the PC
contained in the Neighbour Table, the packet MUST be dropped and contained in the Neighbour Table, the packet MUST be dropped and
processing stops (no challenge is sent in this case, since the processing stops (no challenge is sent in this case, since the
mismatch might be caused by harmless packet reordering on the mismatch might be caused by harmless packet reordering on the
link). Otherwise, the PC contained in the Neighbour Table entry link). Otherwise, the PC contained in the Neighbour Table entry
is set to the received PC, and the packet is accepted. is set to the received PC, and the packet is accepted.
In the algorithm described above, challenge requests are processed
and challenges are sent before the PC/Index pair is verified against
the neighbour table. This simplifies the implementation somewhat
(the node may simply schedule outgoing requests as it walks the
packet during the preparse phase), but relies on the rate-limiting
described in Section 4.3.1.1 to avoid sending too many challenges in
response to replayed packets. As an optimisation, a node MAY ignore
all challenge requests contained in a packet except the last one, and
it MAY ignore a challenge request in the case where it it contained
in a packet with an Index that matches the one in the Neighbour
Table and a PC that is smaller or equal to the one contained in the
Neighbour Table. Since it is still possible to replay a packet with
an obsolete Index, the rate-limiting described in Section 4.3.1.1 is
required even if this optimisation is implemented.
The same is true of challenge replies. However, since validating a
challenge reply is extremely cheap (it's just a bitwise comparison of
two strings of octets), a similar optimisation for challenge replies
is not worthwile.
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
skipping to change at page 13, line 7 skipping to change at page 13, line 31
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 size strictly larger than 32 MAY ignore a PC TLV with an index of length strictly larger than 32
octets. octets. Indices of length 0 are valid: if a node has reliable stable
storage and the packet counter never overflows, then only one index
is necessary, and the value of length 0 is the canonical choice.
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 = 18 | Length | Nonce... | Type = 18 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
skipping to change at page 13, line 31 skipping to change at page 14, line 8
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.
Nonce The nonce uniquely identifying the challenge, an opaque Nonce The nonce uniquely identifying the challenge, an opaque
string of 0 to 192 octets. 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. Nonces of length 0 are valid: if a node has
reliable stable storage, then it may use a sequential counter for
generating nonces which get encoded in the minumum number of octets
required; the value 0 is then encoded as the string of length 0.
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 = 19 | Length | Nonce... | Type = 19 | Length | Nonce...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Fields : Fields :
skipping to change at page 15, line 36 skipping to change at page 16, line 24
| 19 | Challenge Reply | this document | | 19 | Challenge Reply | this document |
+------+-------------------+---------------+ +------+-------------------+---------------+
8. Acknowledgments 8. 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 Donald Eastlake, Toke Hoiland-Jorgensen, Florian Horn,
and Dave Taht. Dave Taht and Martin Vigoureux.
9. References 9. References
9.1. Normative References 9.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 18, line 18 skipping to change at page 19, line 7
o Fixed an issue with packets that contain a successful challenge o Fixed an issue with packets that contain a successful challenge
reply: they should be accepted before checking the PC value. reply: they should be accepted before checking the PC value.
o Clarified that keys are the exact value of the HMAC hash size, and o Clarified that keys are the exact value of the HMAC hash size, and
not subject to preprocessing; this makes management more not subject to preprocessing; this makes management more
deterministic. deterministic.
B.5. Changes since draft-ietf-babel-hmac-04 B.5. Changes since draft-ietf-babel-hmac-04
Use normative language in more places. o Use normative language in more places.
B.6. Changes since draft-ietf-babel-hmac-05
o Do not update RFC 6126bis.
o Clarify that indices and nonces of length 0 are valid.
o Clarify that multiple PC TLVs in a single packet are not allowed.
o Allow discarding challenge requests when they carry an old PC.
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
 End of changes. 15 change blocks. 
30 lines changed or deleted 67 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/