idnits 2.17.1 draft-ietf-manet-nhdp-sec-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4428 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-herberg-manet-nhdp-sec-threats (ref. 'NHDP-sec-threats') Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) U. Herberg 3 Internet-Draft Fujitsu Laboratories of America 4 Intended status: Standards Track T. Clausen 5 Expires: September 13, 2012 LIX, Ecole Polytechnique 6 March 12, 2012 8 Using Integrity Check Values and Timestamps in NHDP 9 draft-ietf-manet-nhdp-sec-01 11 Abstract 13 This document specifies a security extension to the MANET Neighbor 14 Discovery Protocol (NHDP). The extension introduces the use of 15 Integrity Check Values (ICVs) and Timestamps in HELLO messages in 16 order to counter a selection of security threats to NHDP. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 13, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 55 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 56 5. HELLO Message Content . . . . . . . . . . . . . . . . . . . . 5 57 6. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 5 58 7. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 6 59 8. Validating ICVs . . . . . . . . . . . . . . . . . . . . . . . 6 60 9. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 7 61 10. Provisioning of NHDP Routers . . . . . . . . . . . . . . . . . 8 62 11. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 8 63 12. Security Threats Alleviation Analysis . . . . . . . . . . . . 9 64 12.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 12.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 9 66 12.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 9 67 12.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 68 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 14. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 71 16. Normative References . . . . . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 This document specifies the use of Integrity Check Values (ICVs) in 77 the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130] for 78 countering a selection of the security threats analyzed in 79 [NHDP-sec-threats]. It specifies the use of such ICVs for validating 80 the identity of the originator of a HELLO message, for validating of 81 the content (i.e., the links being advertised) of a HELLO message, 82 and for validating the message integrity. The protection so offered 83 against the threats in [NHDP-sec-threats] is evaluated. 85 This document uses the TLVs defined in [packetbb-sec] within NHDP 86 HELLO messages, and specifies extensions (as enabled by Section 16 in 87 [RFC6130]) to the HELLO message processing. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 93 "OPTIONAL" in this document are to be interpreted as described in RFC 94 2119 [RFC2119]. 96 Additionally, this document uses the terminology of [RFC5444], 97 [packetbb-sec], [RFC6130] and [NHDP-sec-threats]. 99 Additionally, this document introduces the following terminology: 101 NHDP Router: A MANET router, running NHDP as specified in [RFC6130]. 103 3. Applicability Statement 105 [RFC6130] enables extensions to recognize additional reasons for 106 rejecting a message as malformed, and mentions security as an 107 explicit example. 109 This document: 111 o Specifies an extension to [RFC6130] by providing a framework for 112 associating ICVs to messages and for using such invalid ICVs as 113 one such "additional reason" for rejecting a message as malformed. 115 o Uses the containers for carrying ICVs and timestamps, as well as 116 the registries for cryptographic code-points, specified in 117 [packetbb-sec]. 119 o Is applicable where ICVs are an appropriate security solution. 120 Note that the choice of the cryptographic algorithm are to be made 121 for each given deployment, and that the choice of such is out of 122 scope for this document. 124 o Assumes that a router which is able to generate correct ICVs 125 (e.g., has valid cryptographic keys), is considered trusted. 127 o Assumes that the TLV type extension of the ICV Message TLV, as 128 defined in [packetbb-sec] is 1, i.e., that an ICV is composed of a 129 cryptographic function over a hash value of the message as defined 130 in Section 12 of [packetbb-sec]. 132 This document does NOT: 134 o Specify how to distribute cryptographic keys, shared secrets, 135 parameters for cryptographic algorithms, etc. 137 o Specify how to detect compromised routers with valid keys. 139 o Specify how to handle compromised routers with valid keys, i.e., 140 key-revocation etc. 142 4. Protocol Overview and Functioning 144 The framework presented in this document provides two 145 functionalities: 147 o Generation of an ICV for an outgoing HELLO message. 149 o Verification of an ICV in order to determine if an incoming HELLO 150 message SHOULD be rejected as malformed. 152 When an NHDP Router generates a HELLO message on an interface, this 153 extension: 155 o Specifies how to calculate an ICV for the message. 157 o Specifies how to include that ICV by way of a TLV. 159 The framework allows to add several ICVs with different hash and 160 cryptographic functions. 162 [RFC6130] allows to reject incoming HELLO messages prior to 163 processing by NHDP. This extension specifies that for each ICV TLV 164 in the Message TLV Block of an incoming message, the message MUST be 165 rejected if the ICV can not be verified. 167 5. HELLO Message Content 169 HELLO messages MUST be generated as specified in [RFC6130]. In 170 addition, in order to conform to this specification, each HELLO 171 message MUST contain: 173 o A element (as specified in [RFC5444]). 175 o A element (as specified in [RFC5444]). 177 o One, or more, ICV TLVs (as specified in [packetbb-sec]), generated 178 according to Section 6. 180 If protection against replay attacks is desired, then a HELLO message 181 MUST also contain: 183 o A TIMESTAMP TLV (as specified in [packetbb-sec]). 185 6. HELLO Message Generation 187 After the HELLO message generation and before HELLO message 188 transmission, as permitted by [RFC6130], the additional elements 189 specified in Section 5 MUST (unless already present) be added to an 190 outgoing HELLO message. 192 The following processing steps MUST be taken for each cryptographic 193 algorithm that is used for generating ICVs for a HELLO message: 195 1. All existing TLVs (if any) of type ICV are temporarily removed 196 from the message. Any temporarily removed TLVs MUST be stored, 197 for being reinserted into the message in step 5. 199 2. The message size is recalculated to the size of the message 200 without the temporarily removed ICV TLVs. 202 3. The ICV value is calculated over the whole message (as resulting 203 after step 2) according to the chosen hash and cryptographic 204 function and according to Section 12.1 of [packetbb-sec]. 206 4. A TLV of type ICV and with type extension 1 is added in the 207 message TLV block, with the content according to Section 12.1 of 208 [packetbb-sec]. 210 5. All other ICV TLVs that have been temporary removed, are 211 restored. 213 6. The message size is recalculated, including the new ICV TLV as 214 well as any restored temporarily removed ICV TLVs. 216 7. HELLO Message Processing 218 [RFC6130] specifies that: 220 "On receiving a HELLO message, a router MUST first check if the 221 message is invalid for processing by this router" 223 [RFC6130] proceeds to give a number of conditions that, each, will 224 lead to a rejection of the HELLO message. This document adds the 225 following conditions to that list which, if true, MUST cause NHDP to 226 consider the HELLO message as invalid for processing: 228 o The HELLO message does not include a element. 230 o The HELLO message does not include a element. 232 o The Message TLV block of the HELLO message contains more than one 233 TIMESTAMP TLV with the same "Type Extension". 235 o Any ICV in the Message TLV block of the HELLO message is invalid, 236 according to Section 8. 238 o The value of the TIMESTAMP TLV of the message is invalid as 239 specified in Section 9. 241 8. Validating ICVs 243 The included ICVs in an incoming HELLO message are processed as 244 follows: 246 1. For each ICV Message TLV in the HELLO message, the ICV TLV is 247 temporarily removed if: 249 * The ICV TLV "Type Extension" is not equal to 1; OR 251 * The ICV TLV "Type Extension" is equal to 1, AND the hash 252 function and the cryptographic function indicated in that ICV 253 TLV are unknown to the NHDP Router. 255 2. If no ICV TLVs remain after step 1, validation fails and the 256 message MUST be considered invalid for processing and MUST be 257 discarded. 259 3. Otherwise, the message with the remaining ICV TLVs (henceforth: 260 "Known ICV TLVs") is processed as follows: 262 1. All Known ICV TLVs are temporarily removed from the message, 263 and the message size is recalculated. 265 2. Each of the temporarily removed Known ICV TLVs from the step 266 above is, then, validated as follows: 268 + Calculate the message-hash-value over the HELLO message, 269 using the hash function indicated by in 270 the ICV TLV. 272 + Calculate the message-ICV-Value over the resulting 273 message-hash-value, using the cryptographic function, and 274 the key ID, indicated by and 275 in the ICV TLV. 277 + If message-ICV-Value differs from the value of 278 in the ICV, then the ICV validation has failed: 280 - The HELLO message MUST be considered invalid for 281 processing and MUST be discarded. 283 4. Then: 285 A. All temporarily removed ICV TLVs are restored (i.e., all ICV 286 TLVs temporarily removed in both step 1 and step 3). 288 B. The message size is restored. 290 5. The message can now be processed according to [RFC6130]. 292 9. Validating a Timestamp 294 If an NHDP Router is configured to require protection against replay 295 attacks, then TIMESTAMP TLVs in incoming HELLO messages MUST be 296 validated. Unless this validation succeeds, the HELLO message MUST 297 be discarded. 299 In order to undertake this validation, an NHDP Router which requires 300 protection against replay attacks MUST: 302 o Be configured with a list of TIMESTAMP "Type Extensions", which it 303 supports. 305 o For each of these TIMESTAMP "Type Extensions", define 306 MAX_TIMESTAMP_DIFF as the maximum allowed difference between the 307 "expected timestamp value" and the "timestamp value" encoded in 308 the TIMESTAMP TLV of an incoming HELLO message (e.g., to 309 accommodate for propagation delays across a network). 311 An incoming HELLO message MUST be considered invalid if: 313 o The Message TLV Block of the HELLO message does not contain a 314 TIMESTAMP TLV with a "Type Extension" matching (one of) the 315 timestamp types, known by the receiving NHDP Router. 317 o The Message TLV Block of the HELLO message does contain a 318 TIMESTAMP TLV with a Type Extension matching (one of) the 319 timestamp types, known by the receiving NHDP Router, but where the 320 value of that TIMESTAMP TLV differs from the expected value by 321 more than MAX_TIMESTAMP_DIFF. 323 10. Provisioning of NHDP Routers 325 Before an NHDP Router is able to generate ICVs or validate messages, 326 it MUST acquire the cryptographic key(s) and any parameters of the 327 cryptographic algorithm from all other routers that are to 328 participate in the network. This document does not specify how a 329 router acquires the cryptographic keys and parameters used in the 330 MANET. 332 11. Summary of NHDP Interaction 334 When using the NHDP security extension, specified in this document, 335 the following MUST be observed: 337 o HELLO messages MUST be generated according to [RFC6130]. 339 o Outgoing HELLO messages, generated by [RFC6130] MUST be processed 340 according to Section 6 after their generation and prior to their 341 transmission by [RFC6130], in order that (an) ICV TLV(s) can be 342 generated and inserted, as allowed by Section 16 in [RFC6130]. 344 o Any other extension to [RFC6130] which adds information to a HELLO 345 message MUST do so prior to the HELLO message being handed off for 346 ICV generation according to this specification. 348 o An incoming HELLO message MUST be processed according to Section 7 349 prior to processing by [RFC6130] as allowed in Section 16 in 350 [RFC6130]. 352 o Any other NHDP extension, which has added information to a HELLO 353 message and which wishes that the HELLO message is rejected if an 354 ICV is not valid, MUST likewise process the HELLO message only 355 after its processing according to this specification. 357 12. Security Threats Alleviation Analysis 359 This section briefly summarizes which of the security threats, from 360 among those detailed in [NHDP-sec-threats], that are alleviated by 361 the framework presented in this document. 363 12.1. Jamming 365 Since jamming is a physical layer issue, it cannot be alleviated by 366 protocols on the routing layer. This framework does not counteract 367 jamming attacks. 369 12.2. Identity Spoofing 371 As only NHDP Routers possessing valid cryptographic keys are able to 372 add ICV TLVs HELLO messages, in a way which permits that these be 373 validated successfully, identity spoofing is counteracted. 375 12.3. Link Spoofing 377 Link spoofing is counteracted by the framework specified in this 378 document, with the same argument as in Section 12.2. A router 379 without access to valid cryptographic keys cannot generate valid ICVs 380 for inclusion in a HELLO message. 382 12.4. Replay Attack 384 Replay attacks are only counteracted if TIMESTAMP TLVs are included 385 in HELLO messages. This is optional, and depends on synchronized 386 clocks of all routers in the MANET. An attacker which records 387 messages to replay them later can only do so in the time interval 388 between the timestamp that is contained in the TIMESTAMP TLV and 389 MAX_TIMESTAMP_DIFF seconds later. As an attacker cannot modify the 390 content of the TIMESTAMP TLV (since it does not possess the valid 391 cryptographic keys for generating valid ICV TLVs), it cannot replay 392 messages after this time interval. Within this time interval, 393 however, it is still possible to replay attacks. 395 13. IANA Considerations 397 This document has no actions for IANA. 399 14. Security Considerations 401 This document specifies a protocol extension to NHDP which allows to 402 alleviate some of the security threats of NHDP analyzed in 403 [NHDP-sec-threats]. 405 If no synchronized clocks are available in the MANET, replay attacks 406 cannot be counteracted by the framework provided by this document. 408 The framework provided by this document does not avoid or detect 409 security attacks by routers possessing the cryptographic keys that 410 are used to generate ICVs for messages. 412 This document depends on the quality of the used cipher algorithm and 413 hash function, and is as such subject the same security 414 considerations as applies to these. 416 This document relies on an out-of-band protocol or mechanism for 417 distributing keys and cryptographic parameters. The security 418 considerations of such protocol or mechanism also apply. 420 This document does also not provide a key revocation mechanism. 422 15. Acknowledgments 424 The authors would like to thank Jiazi Yi (Ecole Polytechnique) for 425 his review and comments to this document. 427 16. Normative References 429 [NHDP-sec-threats] 430 Herberg, U., Clausen, T., and J. Yi, "Security Threats for 431 NHDP", work in 432 progress draft-herberg-manet-nhdp-sec-threats-01.txt, 433 March 2012. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 439 "Generalized MANET Packet/Message Format", RFC 5444, 440 February 2009. 442 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 443 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 444 RFC 6130, March 2011. 446 [packetbb-sec] 447 Herberg, U. and T. Clausen, "Integrity Check Value and 448 Timestamp TLV Definitions for MANETs", work in 449 progress draft-ietf-manet-packetbb-sec-09.txt, March 2012. 451 Authors' Addresses 453 Ulrich Herberg 454 Fujitsu Laboratories of America 455 1240 E. Arques Ave. 456 Sunnyvale, CA, 94085, 457 USA 459 Email: ulrich@herberg.name 460 URI: http://www.herberg.name/ 462 Thomas Heide Clausen 463 LIX, Ecole Polytechnique 464 91128 Palaiseau Cedex, 465 France 467 Phone: +33 6 6058 9349 468 Email: T.Clausen@computer.org 469 URI: http://www.thomasclausen.org/