[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,
              <https://www.rfc-editor.org/info/rfc2104>.




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, <https://www.rfc-editor.org/info/rfc4493>.

   [RFC6126]  Chroboczek, J., "The Babel Routing Protocol", RFC 6126,
              DOI 10.17487/RFC6126, April 2011,
              <https://www.rfc-editor.org/info/rfc6126>.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <https://www.rfc-editor.org/info/rfc6347>.

   [RFC7788]  Stenberg, M., Barth, S., and P. Pfister, "Home Networking
              Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April
              2016, <https://www.rfc-editor.org/info/rfc7788>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/