draft-ietf-babel-hmac-10.txt   draft-ietf-babel-hmac-11.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 18, 2020 August 17, 2019 Expires: February 26, 2021 August 25, 2020
MAC authentication for the Babel routing protocol MAC authentication for the Babel routing protocol
draft-ietf-babel-hmac-10 draft-ietf-babel-hmac-11
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 18, 2020. This Internet-Draft will expire on February 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 10, line 34 skipping to change at page 10, line 34
it MAY ignore a challenge request in the case where it is contained it MAY ignore a challenge request in the case where it is contained
in a packet with an Index that matches the one in the Neighbour 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 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 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 an obsolete Index, the rate-limiting described in Section 4.3.1.1 is
required even if this optimisation is implemented. required even if this optimisation is implemented.
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 worthwile. 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
skipping to change at page 16, line 24 skipping to change at page 16, line 24
attacker that is able to capture packets; it is therefore vulnerable attacker that is able to capture packets; it is therefore vulnerable
to brute-force attacks. Keys must be chosen in a manner that makes to brute-force attacks. Keys must be chosen in a manner that makes
them difficult to guess. Ideally, they should have a length of 32 them difficult to guess. Ideally, they should have a length of 32
octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly. octets (both for HMAC-SHA256 and Blake2s), and be chosen randomly.
If, for some reason, it is necessary to derive keys from a human- If, for some reason, it is necessary to derive keys from a human-
readable passphrase, it is recommended to use a key derivation readable passphrase, it is recommended to use a key derivation
function that hampers dictionary attacks, such as PBKDF2 [RFC2898], function that hampers dictionary attacks, such as PBKDF2 [RFC2898],
bcrypt [BCRYPT] or scrypt [RFC7914]. In that case, only the derived bcrypt [BCRYPT] or scrypt [RFC7914]. In that case, only the derived
keys should be communicated to the routers; the original passphrase keys should be communicated to the routers; the original passphrase
itself should be kept on the host used to perform the key generation itself should be kept on the host used to perform the key generation
(e.g., an administators secure laptop computer). (e.g., an administator's secure laptop computer).
While it is probably not possible to be immune against denial of While it is probably not possible to be immune against denial of
service (DoS) attacks in general, this protocol includes a number of service (DoS) attacks in general, this protocol includes a number of
mechanisms designed to mitigate such attacks. In particular, mechanisms designed to mitigate such attacks. In particular,
reception of a packet with no correct MAC creates no local Babel reception of a packet with no correct MAC creates no local Babel
state (Section 4.3). Reception of a replayed packet with correct state (Section 4.3). Reception of a replayed packet with correct
MAC, on the other hand, causes a challenge to be sent; this is MAC, on the other hand, causes a challenge to be sent; this is
mitigated somewhat by requiring that challenges be rate-limited mitigated somewhat by requiring that challenges be rate-limited
(Section 4.3.1.1). (Section 4.3.1.1).
skipping to change at page 21, line 16 skipping to change at page 21, line 16
o Renamed HMAC to MAC throughout, relevant rewording. o Renamed HMAC to MAC throughout, relevant rewording.
o Made it mandatory to rate-limit challenge replies in addition to o Made it mandatory to rate-limit challenge replies in addition to
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
o Fixed minor typos.
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. 7 change blocks. 
6 lines changed or deleted 10 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/