idnits 2.17.1 draft-lemon-homenet-babel-security-latest-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 130: '...unicast, the key MUST be present. Oth...' RFC 2119 keyword, line 136: '...ed Babel message MUST carry one of the...' RFC 2119 keyword, line 137: '...ure. These TLVs MUST be the last TLV ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 23, 2017) is 2376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6126 (Obsoleted by RFC 8966) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Informational October 23, 2017 5 Expires: April 26, 2018 7 Babel Security Model 8 draft-lemon-homenet-babel-security-latest-00 10 Abstract 12 This document describes how to add authenticity to Babel messages so 13 as to prevent malicious tampering or black hole attacks. Peer trust 14 is outside the scope of this document. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 26, 2018. 33 Copyright Notice 35 Copyright (c) 2017 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Message Authenticity . . . . . . . . . . . . . . . . . . . . 2 52 3. Babel Extensions . . . . . . . . . . . . . . . . . . . . . . 3 53 3.1. Data Structures . . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2.1. MAC TLV . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.2.2. Signature TLV . . . . . . . . . . . . . . . . . . . . 4 57 3.3. Message Processing . . . . . . . . . . . . . . . . . . . 4 58 4. Pairing and Trust . . . . . . . . . . . . . . . . . . . . . . 5 59 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 62 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Babel is a loop-avoiding distance-vector routing protocol suitable 68 for wired and wireless mesh networks. As defined in [RFC6126], Babel 69 is a completely secure protocol. It offers no message authenticity 70 or confidentiality, making it vulnerable to the following attacks: 72 o Attacker black holes: An attacker advertises cheap routes to 73 attract direct legitimate traffic to an invalid host. 75 o Advertisement tampering: An attacker can steer legitimate traffic 76 away from legitimate hosts by maliciously increasing advertisement 77 costs. 79 The specification suggests that one of two approaches can mitigate 80 these attacks: 82 1. Lower-layer security mechanisms, e.g., link-layer authenticated 83 encryption, or 85 2. Authenticating Babel packets directly via, e.g., a cryptographic 86 MAC computed using a shared key. 88 In this document, we outline the mechanics necessary for the second 89 strategy. Namely, building message authentication into Babel. 91 2. Message Authenticity 93 Message authenticity requires receivers to verify the contents of 94 each received message. This can be done in one of two ways, 95 depending on the type of destination address used in the message: 97 o For multicast addresses, the message must be digitally signed. 98 This allows any recipient with that trusts the public key to 99 verify the message. We recommend EdDSA-Ed25519 [RFC8032] for 100 digital signatures. (EdDSA-Ed25519 signatures have 64-octet 101 signatures instead of 114-octet signatures.) 103 o For unicast addresses, the message must contain a cryptographic 104 MAC generated with a secret key shared between the sender and 105 receiver. We recommend HMAC [RFC2104] or CMAC [RFC4493] for as 106 the MAC algorithm. 108 It is assumed that each Babel speaker, i.e., each speaker ID, has an 109 associated public and private key pair. Private keys are used to 110 sign multicast messages. Receivers use (trusted) public keys to 111 verify said messages. Two speakers that trust one another can use 112 these keys to establish a shared secret using mutually authenticated 113 DTLS [RFC6347]. DTLS is not used to encrypt and authenticate 114 messages afterwards. It is only used to derive a shared secret. 116 In addition to these keys, routers maintain a monotonically 117 increasing sequence number that is incremented whenever a message is 118 signed or MAC'd. This serves as a unique nonce suitable for replay 119 detection, if desired. 121 3. Babel Extensions 123 The Babel message protocol and data structures must be amended to 124 store peer trust information, i.e., cryptographic keying material. 126 3.1. Data Structures 128 Neighbor tables must be extended to store an optional shared key and 129 corresponding sequence number for each (interface, address) tuple. 130 If the address is unicast, the key MUST be present. Otherwise, the 131 address is multicast, and each message is signed using the speaker's 132 private key. 134 3.2. Messages 136 Each authenticated Babel message MUST carry one of the two following 137 new TLVs: MAC or Signature. These TLVs MUST be the last TLV in a 138 single Babel message. Their authenticator values are computed over 139 all preceding TLVs, as well as the (T, L, Reserved, Sequence Number) 140 headers in the parent TLV. This authenticates the entire message 141 contents. 143 The structure of each TLV defined in the following sections. 145 3.2.1. MAC TLV 147 The MAC TLV contains the 4-octet sequence number and 16-octet MAC 148 value, as shown below. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type = X | Length | Reserved | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Sequence Number | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | MAC value | 158 | | 159 | | 160 | | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 3.2.2. Signature TLV 165 The Signature TLV contains the 4-octet sequence number, 16-octet key 166 identifier, and 64-octet signature. The key identifier is the 167 (truncated) SHA-256 hash of the sender's public key. The signature 168 is the EdDSA signature, formatted according to [RFC8032]. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type = X | Length | Reserved | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Sequence Number | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Key Identifier | 178 | | 179 | | 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 / Signature / 183 / / 184 / .... / 185 / / 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 3.3. Message Processing 190 MACs and signatures are computed over all data preceding the actual 191 MAC or signature payload, including the headers of the MAC or 192 Signature TLV. Upon receipt of message with a MAC or Signature TLV, 193 the receipient must verify its correctness before processing. The 194 verification process for unicast messages works as follows: 196 1. If there is no MAC TLV, ignore the message. 198 2. Compute and verify the MAC using the secret key associated with 199 the sender. If the MAC is invalid, ignore the packet. 201 3. If the MAC is valid, process the message as per normal. 203 Verification of multicast messages works as follows: 205 1. If there is no Signature TLV, ignore the message. 207 2. If there is no public key whose identifier matches the key 208 identifier in the Signature TLV, ignore the message. 210 3. Verify the signature in the Signature TLV. If invalid, ignore 211 the message. 213 4. If valid, process the message as per normal. 215 4. Pairing and Trust 217 Device pairing and trust establishment is done via HNCP [RFC7788]. 219 5. IANA Considerations 221 This document makes no requests to IANA at this time. 223 6. Security Considerations 225 This document describes a mechanism to protect Babel protocol 226 messages. Trust in keys used to derive shared secrets and protect is 227 deferred to HNCP [RFC7788]. 229 7. Acknowledgments 231 The author would like to thank members of the HomeNet security group 232 for helpful discussions that led to the production of this draft. 234 8. Normative References 236 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 237 Hashing for Message Authentication", RFC 2104, 238 DOI 10.17487/RFC2104, February 1997, 239 . 241 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 242 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 243 2006, . 245 [RFC6126] Chroboczek, J., "The Babel Routing Protocol", RFC 6126, 246 DOI 10.17487/RFC6126, April 2011, 247 . 249 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 250 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 251 January 2012, . 253 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 254 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 255 2016, . 257 [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital 258 Signature Algorithm (EdDSA)", RFC 8032, 259 DOI 10.17487/RFC8032, January 2017, 260 . 262 Author's Address 264 Ted Lemon 265 Nominum, Inc. 266 800 Bridge Parkway, Suite 100 267 Redwood City, California 94065 268 United States of America 270 Email: Ted.Lemon@nominum.com