--- 1/draft-ietf-babel-hmac-02.txt 2018-12-26 12:13:08.475259342 -0800 +++ 2/draft-ietf-babel-hmac-03.txt 2018-12-26 12:13:08.511260204 -0800 @@ -1,43 +1,43 @@ Network Working Group C. Do Internet-Draft W. Kolodziejak Obsoletes: 7298 (if approved) J. Chroboczek Updates: 6126bis (if approved) IRIF, University of Paris-Diderot -Intended status: Standards Track December 23, 2018 -Expires: June 26, 2019 +Intended status: Standards Track December 26, 2018 +Expires: June 29, 2019 HMAC authentication for the Babel routing protocol - draft-ietf-babel-hmac-02 + draft-ietf-babel-hmac-03 Abstract - This document describes a cryptographic authentication for the Babel - routing protocol that has provisions for replay avoidance. This - document updates RFC 6126bis and obsoletes RFC 7298. + This document describes a cryptographic authentication mechanism for + the Babel routing protocol that has provisions for replay avoidance. + This document updates RFC 6126bis and obsoletes RFC 7298. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 26, 2019. + This Internet-Draft will expire on June 29, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -69,22 +69,23 @@ 5.4. Challenge Reply TLV . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.2. Informational References . . . . . . . . . . . . . . . . 15 Appendix A. Incremental deployment and key rotation . . . . . . 15 Appendix B. Changes from previous versions . . . . . . . . . . . 16 B.1. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16 - B.2. Changes since draft-ietf-babel-hmac-00 . . . . . . . . . 16 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 + B.2. Changes since draft-ietf-babel-hmac-01 . . . . . . . . . 16 + B.3. Changes since draft-ietf-babel-hmac-02 . . . . . . . . . 16 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction By default, the Babel routing protocol trusts the information 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 network, causing a variety of potential issues. In particular, an attacker might: o spoof a Babel packet, and redirect traffic by announcing a smaller @@ -133,23 +134,23 @@ o that the Hashed Message Authentication Code (HMAC) being used is 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 lifetime of a key. The first assumption is a property of the HMAC being used. The second assumption can be met either by using a robust random number - generator and sufficiently large indices and nonces, by using a - reliable hardware clock, or by rekeying whenever a collision becomes - likely. + generator [RFC4086] and sufficiently large indices and nonces, by + using a reliable hardware clock, or by rekeying whenever a collision + becomes likely. If the assumptions above are met, the protocol described in this document has the following properties: o it is invulnerable to spoofing: any packet accepted as authentic is the exact copy of a packet originally sent by an authorised 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 @@ -321,21 +322,21 @@ interface MTU (Section 4 of [RFC6126bis]). For an interface on which HMAC protection is configured, the TLV aggregation logic MUST take into account the overhead due to PC TLVs (one in each packet) and HMAC TLVs (one per configured key). Before sending a packet, the following actions are performed: o a PC TLV containing the PC and Index associated with the outgoing interface is appended to the packet body; the PC is incremented by a strictly positive amount (typically just 1); if the PC - overflows, a new index is generated; + overflows, a fresh index is generated; o for each key configured on the interface, an HMAC is computed as specified in Section 4.1 above, and an HMAC TLV is appended to the packet trailer (see Section 4.2 of [RFC6126bis]). 4.3. Packet Reception When a packet is received on an interface that is configured for HMAC protection, the following steps are performed before the packet is passed to normal processing: @@ -466,21 +467,21 @@ table, and is normally discarded when the neighbour table entry expires. Implementations MUST ensure that an (Index, PC) pair is discarded within a finite time since the last time a packet has been accepted. In particular, unsuccessful challenges MUST NOT prevent an (Index, PC) pair from being discarded for unbounded periods of time. Implementations that use a Hello history (Appendix A of [RFC6126bis]) may discard the (Index, PC) pair whenever the Hello history becomes empty. Other impementations may use a timer that is reset whenever a packet is accepted, and discard the (Index, PC) pair whenever the - timer expires (an timeout of 5 min is suggested). + timer expires (a timeout of 5 min is suggested). 5. Packet Format 5.1. HMAC TLV 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 | HMAC... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- @@ -509,25 +510,26 @@ | Index... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to TBD to indicate a PC TLV. Length The length of the body, exclusive of the Type and Length fields. - PC The Packet Counter (PC), which is increased with every - packet sent over this interface. A new index MUST be - generated whenever the PC overflows. + PC The Packet Counter (PC), a 32-bit (4 octet) unsigned + integer which is increased with every packet sent over this + interface. A fresh index MUST be generated whenever the PC + overflows. - Index The sender's Index. + Index The sender's Index, an opaque string of 0 to 32 octets. Indices are limited to a size of 32 octets: a node MUST NOT send a 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 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 @@ -535,21 +537,22 @@ | Type | Length | Nonce... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fields : Type Set to TBD to indicate a Challenge Request TLV. Length The length of the body, exclusive of the Type and Length fields. - Nonce The nonce uniquely identifying the challenge. + Nonce The nonce uniquely identifying the challenge, an opaque + string of 0 to 192 octets. Nonces are limited to a size of 192 octets: a node MUST NOT send a 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 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 @@ -587,21 +590,21 @@ (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 (more precisely, indices must be unique for a given (key, source) pair, and nonces must be unique for a given (key, source, destination) triple). 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. If uniqueness cannot be guaranteed (e.g., because a hardware clock has been reset), then rekeying is necessary. The expiry mechanism mandated in Section 4.4 is required to prevent an attacker from delaying an authentic packet by an unbounded amount of time. If an attacker is able to delay the delivery of a packet (e.g., because it is located at a layer 2 switch), then the packet will be accepted as long as the corresponding (Index, PC) pair is present at the receiver. If the attacker is able to cause the (Index, PC) pair to persist for arbitrary amounts of time (e.g., by causing failed challenges), then it is able to delay the packet by @@ -618,21 +621,21 @@ 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 - IANA is instructed to allocate the following values in the Babel TLV + IANA is requested to allocate the following values in the Babel TLV Numbers registry: +------+-------------------+---------------+ | Type | Name | Reference | +------+-------------------+---------------+ | TBD | HMAC | this document | | | | | | TBD | PC | this document | | | | | | TBD | Challenge Request | this document | @@ -680,20 +683,25 @@ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. 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. + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, + . + [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, . [RFC7298] Ovsienko, D., "Babel Hashed Message Authentication Code (HMAC) Cryptographic Authentication", RFC 7298, DOI 10.17487/RFC7298, July 2014, . @@ -729,26 +737,34 @@ o Removed the appendix about the packet trailer, this is now in rfc6126bis. o Removed the appendix with implicit indices. o Clarified the definitions of acronyms. o Limited the size of nonces and indices. -B.2. Changes since draft-ietf-babel-hmac-00 +B.2. Changes since draft-ietf-babel-hmac-01 o Made BLAKE2s a recommended HMAC algorithm. o Added requirement to expire per-neighbour crypto state. +B.3. Changes since draft-ietf-babel-hmac-02 + + o Clarified that PCs are 32-bit unsigned integers. + + o Clarified that indices and nonces are of arbitrary size. + + o Added reference to RFC 4086. + Authors' Addresses Clara Do IRIF, University of Paris-Diderot 75205 Paris Cedex 13 France Email: clarado_perso@yahoo.fr Weronika Kolodziejak