Network Working Group T. Lemon Internet-Draft Nominum, Inc. Intended status: Informational October 23, 2017 Expires: April 26, 2018 Babel Security Model draft-lemon-homenet-babel-security-latest-00 Abstract This document describes how to add authenticity to Babel messages so as to prevent malicious tampering or black hole attacks. Peer trust is outside the scope of this document. 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 April 26, 2018. Copyright Notice Copyright (c) 2017 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Lemon Expires April 26, 2018 [Page 1] Internet-Draft Babel Security Model October 2017 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Message Authenticity . . . . . . . . . . . . . . . . . . . . 2 3. Babel Extensions . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 3 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2.1. MAC TLV . . . . . . . . . . . . . . . . . . . . . . . 4 3.2.2. Signature TLV . . . . . . . . . . . . . . . . . . . . 4 3.3. Message Processing . . . . . . . . . . . . . . . . . . . 4 4. Pairing and Trust . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction Babel is a loop-avoiding distance-vector routing protocol suitable for wired and wireless mesh networks. As defined in [RFC6126], Babel is a completely secure protocol. It offers no message authenticity or confidentiality, making it vulnerable to the following attacks: o Attacker black holes: An attacker advertises cheap routes to attract direct legitimate traffic to an invalid host. o Advertisement tampering: An attacker can steer legitimate traffic away from legitimate hosts by maliciously increasing advertisement costs. The specification suggests that one of two approaches can mitigate these attacks: 1. Lower-layer security mechanisms, e.g., link-layer authenticated encryption, or 2. Authenticating Babel packets directly via, e.g., a cryptographic MAC computed using a shared key. In this document, we outline the mechanics necessary for the second strategy. Namely, building message authentication into Babel. 2. Message Authenticity Message authenticity requires receivers to verify the contents of each received message. This can be done in one of two ways, depending on the type of destination address used in the message: Lemon Expires April 26, 2018 [Page 2] Internet-Draft Babel Security Model October 2017 o For multicast addresses, the message must be digitally signed. This allows any recipient with that trusts the public key to verify the message. We recommend EdDSA-Ed25519 [RFC8032] for digital signatures. (EdDSA-Ed25519 signatures have 64-octet signatures instead of 114-octet signatures.) o For unicast addresses, the message must contain a cryptographic MAC generated with a secret key shared between the sender and receiver. We recommend HMAC [RFC2104] or CMAC [RFC4493] for as the MAC algorithm. It is assumed that each Babel speaker, i.e., each speaker ID, has an associated public and private key pair. Private keys are used to sign multicast messages. Receivers use (trusted) public keys to verify said messages. Two speakers that trust one another can use these keys to establish a shared secret using mutually authenticated DTLS [RFC6347]. DTLS is not used to encrypt and authenticate messages afterwards. It is only used to derive a shared secret. In addition to these keys, routers maintain a monotonically increasing sequence number that is incremented whenever a message is signed or MAC'd. This serves as a unique nonce suitable for replay detection, if desired. 3. Babel Extensions The Babel message protocol and data structures must be amended to store peer trust information, i.e., cryptographic keying material. 3.1. Data Structures Neighbor tables must be extended to store an optional shared key and corresponding sequence number for each (interface, address) tuple. If the address is unicast, the key MUST be present. Otherwise, the address is multicast, and each message is signed using the speaker's private key. 3.2. Messages Each authenticated Babel message MUST carry one of the two following new TLVs: MAC or Signature. These TLVs MUST be the last TLV in a single Babel message. Their authenticator values are computed over all preceding TLVs, as well as the (T, L, Reserved, Sequence Number) headers in the parent TLV. This authenticates the entire message contents. The structure of each TLV defined in the following sections. Lemon Expires April 26, 2018 [Page 3] Internet-Draft Babel Security Model October 2017 3.2.1. MAC TLV The MAC TLV contains the 4-octet sequence number and 16-octet MAC value, as shown below. 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 = X | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC value | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2.2. Signature TLV The Signature TLV contains the 4-octet sequence number, 16-octet key identifier, and 64-octet signature. The key identifier is the (truncated) SHA-256 hash of the sender's public key. The signature is the EdDSA signature, formatted according to [RFC8032]. 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 = X | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key Identifier | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Signature / / / / .... / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.3. Message Processing MACs and signatures are computed over all data preceding the actual MAC or signature payload, including the headers of the MAC or Signature TLV. Upon receipt of message with a MAC or Signature TLV, Lemon Expires April 26, 2018 [Page 4] Internet-Draft Babel Security Model October 2017 the receipient must verify its correctness before processing. The verification process for unicast messages works as follows: 1. If there is no MAC TLV, ignore the message. 2. Compute and verify the MAC using the secret key associated with the sender. If the MAC is invalid, ignore the packet. 3. If the MAC is valid, process the message as per normal. Verification of multicast messages works as follows: 1. If there is no Signature TLV, ignore the message. 2. If there is no public key whose identifier matches the key identifier in the Signature TLV, ignore the message. 3. Verify the signature in the Signature TLV. If invalid, ignore the message. 4. If valid, process the message as per normal. 4. Pairing and Trust Device pairing and trust establishment is done via HNCP [RFC7788]. 5. IANA Considerations This document makes no requests to IANA at this time. 6. Security Considerations This document describes a mechanism to protect Babel protocol messages. Trust in keys used to derive shared secrets and protect is deferred to HNCP [RFC7788]. 7. Acknowledgments The author would like to thank members of the HomeNet security group for helpful discussions that led to the production of this draft. 8. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . Lemon Expires April 26, 2018 [Page 5] Internet-Draft Babel Security Model October 2017 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 2006, . [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, DOI 10.17487/RFC6126, April 2011, . [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, . [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, . Author's Address Ted Lemon Nominum, Inc. 800 Bridge Parkway, Suite 100 Redwood City, California 94065 United States of America Email: Ted.Lemon@nominum.com Lemon Expires April 26, 2018 [Page 6]