idnits 2.17.1 draft-ietf-manet-nhdp-sec-02.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 (May 29, 2012) is 4349 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) ** Obsolete normative reference: RFC 6622 (Obsoleted by RFC 7182) == Outdated reference: A later version (-06) exists of draft-ietf-manet-nhdp-sec-threats-00 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 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: November 30, 2012 LIX, Ecole Polytechnique 6 May 29, 2012 8 Using Integrity Check Values and Timestamps For Router Admittance in 9 NHDP 10 draft-ietf-manet-nhdp-sec-02 12 Abstract 14 This document specifies a security extension to the MANET 15 Neighborhood Discovery Protocol (NHDP). The extension introduces the 16 use of Integrity Check Values (ICVs) and Timestamps in HELLO messages 17 in order to provide a router admittance mechanism, and therefore to 18 counter a selection of security threats to NHDP. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on November 30, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 57 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 58 5. HELLO Message Content . . . . . . . . . . . . . . . . . . . . 5 59 6. HELLO Message Generation . . . . . . . . . . . . . . . . . . . 6 60 7. HELLO Message Processing . . . . . . . . . . . . . . . . . . . 6 61 7.1. Invalidating a Message Based on ICVs . . . . . . . . . . . 7 62 7.2. Invalidating a Message Based on Timestamps . . . . . . . . 8 63 8. Provisioning of NHDP Routers . . . . . . . . . . . . . . . . . 9 64 9. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 9 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 11.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 10 68 11.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 10 69 11.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 10 70 11.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 10 71 11.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10 72 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 73 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 75 13.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 This document specifies the use of Integrity Check Values (ICVs) for 81 router admittance in the MANET Neighborhood Discovery Protocol (NHDP) 82 [RFC6130]. It specifies the use of such ICVs for validating the 83 identity of the originator of a HELLO message, for validating of the 84 content (i.e., the links being advertised) of a HELLO message, and 85 for validating the message integrity. 87 This document uses the TLVs defined in [RFC6622] within NHDP HELLO 88 messages, and specifies extensions (as enabled by Section 16 in 89 [RFC6130]) to the HELLO message processing. 91 Schematically, the mechanism specified in this document inserts 92 itself between [RFC6130] processing/generation of HELLO messages and 93 [RFC5444] encoding/decoding as illustrated in Figure 1. 95 Incoming | | Outgoing 96 HELLO Message | /|\ HELLO Message 97 | | 98 | | 99 \|/ | 100 | | 101 +--------------------------------+ 102 | | 103 | RFC5444 Parser / Generator | 104 | | 105 +--------------------------------+ 106 | | 107 Hello Message \|/ /|\ RFC6622 ICVs 108 Parsed | | added 109 D +--------------------------------+ 110 R /_________________ | | 111 O \ICV not | This Specification | 112 P Verified | | 113 +--------------------------------+ 114 | | 115 ICV verified \|/ /|\ HELLO Message 116 | | Generated 117 +--------------------------------+ 118 | | 119 | RFC6130 | 120 | Processing/Generation | 121 +--------------------------------+ 123 Figure 1: Relationship with RFC5444 and RFC6130. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in RFC 130 2119 [RFC2119]. 132 Additionally, this document uses the terminology of [RFC5444], 133 [RFC6130], and [RFC6622]. 135 Additionally, this document introduces the following terminology: 137 NHDP Router: 138 A MANET router, running NHDP as specified in [RFC6130]. 140 3. Applicability Statement 142 [RFC6130] enables extensions to recognize additional reasons for 143 rejecting a message as "badly formed and therefore invalid for 144 processing", and mentions security as an explicit example. 146 This document: 148 o Specifies an extension to [RFC6130] by providing a framework for 149 associating ICVs to messages and for using such invalid ICVs as 150 one such "additional reason" for rejecting a message as "badly 151 formed and therefore invalid for processing". 153 o Uses the containers for carrying ICVs and timestamps, as well as 154 the registries for cryptographic code-points, specified in 155 [RFC6622]. 157 o Is applicable where ICVs are an appropriate security solution. 158 Note that the choice of the cryptographic function are to be made 159 for each given deployment, and that the choice of such is out of 160 scope for this document. 162 o Assumes that a router which is able to generate correct ICVs 163 (e.g., has valid cryptographic keys), is considered trusted. 165 o Assumes that the TLV type extension of the ICV Message TLV, as 166 defined in [RFC6622] is 1, i.e., that an ICV is composed of a 167 cryptographic function over a hash value of the message as defined 168 in Section 12 of [RFC6622]. 170 This document does NOT: 172 o Specify how to distribute cryptographic keys, shared secrets, 173 parameters for cryptographic functions, etc. 175 o Specify how to detect compromised routers with valid keys. 177 o Specify how to handle compromised routers with valid keys, i.e., 178 key-revocation etc. 180 4. Protocol Overview and Functioning 182 The framework presented in this document provides two 183 functionalities: 185 o Generation of an ICV for an outgoing HELLO message. 187 o Verification of an ICV in order to determine if an incoming HELLO 188 message MUST be rejected as "badly formed and therefore invalid 189 for processing" [RFC6130]. 191 When an NHDP Router generates a HELLO message on an interface, this 192 extension: 194 o Specifies how to calculate an ICV for the message. 196 o Specifies how to include that ICV by way of a TLV. 198 The framework allows for adding several ICVs with different hash and 199 cryptographic functions. 201 [RFC6130] allows for rejecting incoming HELLO messages prior to 202 processing by NHDP. This extension specifies that for each ICV TLV 203 in the Message TLV Block of an incoming message, the message MUST be 204 rejected if the ICV can not be verified. 206 5. HELLO Message Content 208 HELLO messages MUST have the content as specified in [RFC6130]. In 209 addition, in order to conform to this specification, each HELLO 210 message MUST contain: 212 o A element (as specified in [RFC5444]). 214 o A element (as specified in [RFC5444]). 216 o One or more ICV TLVs (as specified in [RFC6622]), generated 217 according to Section 6. 219 If protection against replay attacks is desired, then a HELLO message 220 MUST also contain: 222 o A TIMESTAMP TLV (as specified in [RFC6622]). 224 6. HELLO Message Generation 226 After HELLO message generation ([RFC6130] Section 11.1) and before 227 HELLO message transmission ([RFC6130] Section 11.2), as permitted by 228 [RFC6130] Section 12.1, the additional elements specified in 229 Section 5 MUST (unless already present) be added to an outgoing HELLO 230 message. 232 The following processing steps MUST be taken for each cryptographic 233 algorithm that is used for generating ICVs for a HELLO message: 235 1. All existing TLVs (if any) of type ICV are temporarily removed 236 from the message. Any temporarily removed TLVs MUST be stored, 237 for being reinserted into the message in step 5. 239 2. The message size is recalculated to the size of the message 240 without the temporarily removed ICV TLVs. 242 3. The ICV value is calculated over the whole message (as resulting 243 after step 2) according to the chosen hash and cryptographic 244 function and according to Section 12.1 of [RFC6622]. 246 4. A TLV of type ICV and with type extension 1 is added in the 247 Message TLV block, with the content according to Section 12.1 of 248 [RFC6622]. 250 5. All other ICV TLVs that have been temporary removed, are 251 restored. 253 6. The message size is recalculated, including the new ICV TLV as 254 well as any restored temporarily removed ICV TLVs. 256 7. HELLO Message Processing 258 [RFC6130] specifies that: 260 "On receiving a HELLO message, a router MUST first check if the 261 message is invalid for processing by this router" 263 [RFC6130] proceeds to give a number of conditions that, each, will 264 lead to a rejection of the HELLO message as "badly formed and 265 therefore invalid for processing". This document adds the following 266 conditions to that list which, if true, MUST cause NHDP to consider 267 the HELLO message as invalid for processing: 269 o The HELLO message does not include a element. 271 o The HELLO message does not include a element. 273 o The Message TLV block of the HELLO message contains more than one 274 TIMESTAMP TLV with the same type extension. 276 o Validation of ICVs in the Message TLV block of the HELLO message 277 fails, according to Section 7.1. 279 o If protection against replay attacks is desired, validation of the 280 TIMESTAMP TLV of the message fails, according to Section 7.2. 282 7.1. Invalidating a Message Based on ICVs 284 1. For each ICV Message TLV in the HELLO message, the ICV TLV is 285 temporarily removed if: 287 * The ICV Message TLV type extension is not equal to 1; OR 289 * The ICV Message TLV type extension is equal to 1, AND the hash 290 function and the cryptographic function indicated in that ICV 291 Messsage TLV are unknown to the NHDP Router. 293 2. If no ICV Message TLVs remain after step 1, then validation 294 fails: 296 * The HELLO message MUST be considered "badly formed and 297 therefore invalid for processing", and MUST be discarded. 299 3. Otherwise, the HELLO message with the remaining ICV Message TLVs 300 (henceforth: "Known ICV Message TLVs") is processed as follows: 302 1. All Known ICV Message TLVs are temporarily removed from the 303 message, and the message size is recalculated. 305 2. Each of the temporarily removed Known ICV Message TLVs from 306 the step above is, then, processed as follows: 308 + Calculate the message-hash-value over the HELLO message, 309 using the hash function indicated by in 310 the Known ICV Message TLV. 312 + Calculate the message-ICV-Value over the resulting 313 message-hash-value, using the cryptographic function, and 314 the key ID, indicated by and 315 in the Known ICV Message TLV. 317 + If message-ICV-Value differs from the value of 318 in the Known ICV Message TLV, then validation fails: 320 - The HELLO message MUST be considered "badly formed and 321 therefore invalid for processing", and MUST be 322 discarded. 324 4. Otherwise, the message is considered (with respect to this 325 specification) "valid for processing", and: 327 A. All temporarily removed ICV Message TLVs (i.e., all ICV TLVs 328 temporarily removed in both step 1 and step 3) are restored. 330 B. The message size is restored. 332 7.2. Invalidating a Message Based on Timestamps 334 An NHDP Router which requires protection against replay attacks MUST: 336 o Be configured with a list of TIMESTAMP type extensions, which it 337 supports. 339 o For each of these TIMESTAMP type extensions, define 340 MAX_TIMESTAMP_DIFF as the maximum allowed difference between the 341 "expected timestamp value" and the "timestamp value" encoded in 342 the TIMESTAMP TLV of an incoming HELLO message (e.g., to 343 accommodate for propagation delays across a network). 345 A HELLO message MUST be considered "badly formed and therefore 346 invalid for processing", and MUST be discarded if either of the two 347 following conditions are true: 349 o The Message TLV Block of the HELLO message does not contain a 350 TIMESTAMP TLV with a type extension matching (one of) the 351 timestamp types, known by the receiving NHDP Router. 353 o The Message TLV Block of the HELLO message does contain a 354 TIMESTAMP TLV with a type extension matching (one of) the 355 timestamp types, known by the receiving NHDP Router, but where the 356 value of that TIMESTAMP TLV differs from the expected value by 357 more than MAX_TIMESTAMP_DIFF. 359 8. Provisioning of NHDP Routers 361 Before an NHDP Router is able to generate ICVs or validate messages, 362 it MUST acquire the cryptographic key(s) and any parameters of the 363 cryptographic function from all other routers that are to participate 364 in the network. This document does not specify how a router acquires 365 the cryptographic keys and parameters used in the MANET. 367 9. Summary of NHDP Interaction 369 When using the NHDP security extension, specified in this document, 370 the following MUST be observed: 372 o HELLO messages MUST be generated according to [RFC6130]. 374 o Outgoing HELLO messages, generated by [RFC6130], MUST be processed 375 according to Section 6 after their generation and prior to their 376 transmission by [RFC6130], in order that (an) ICV TLV(s) can be 377 generated and inserted, as allowed by Section 16 in [RFC6130]. 379 o Any other extension to [RFC6130] which adds information to a HELLO 380 message MUST do so prior to the HELLO message being handed off for 381 ICV generation according to this specification. 383 o An incoming HELLO message MUST be processed according to Section 7 384 prior to processing by [RFC6130] as allowed in Section 16 in 385 [RFC6130]. 387 o Any other NHDP extension, which has added information to a HELLO 388 message and which wishes that the HELLO message is rejected if an 389 ICV is not valid, MUST likewise process the HELLO message only 390 after its processing according to this specification. 392 10. IANA Considerations 394 This document has no actions for IANA. 396 11. Security Considerations 398 This document specifies a protocol extension to NHDP which allows for 399 alleviating some of the security threats of NHDP analyzed in 400 [NHDP-sec-threats]. 402 11.1. Alleviated Attacks 404 This section briefly summarizes which of the security threats, from 405 among those detailed in [NHDP-sec-threats], that are alleviated by 406 the framework presented in this document. 408 11.1.1. Identity Spoofing 410 As only NHDP Routers possessing valid cryptographic keys are able to 411 add ICV TLVs HELLO messages, in a way which permits that these be 412 validated successfully, identity spoofing is counteracted. 414 11.1.2. Link Spoofing 416 Link spoofing is counteracted by the framework specified in this 417 document, with the same argument as in Section 11.1.1. A router 418 without access to valid cryptographic keys cannot generate valid ICVs 419 for inclusion in a HELLO message. 421 11.1.3. Replay Attack 423 Replay attacks are only counteracted if TIMESTAMP TLVs are included 424 in HELLO messages. This is optional, and depends on synchronized 425 clocks of all routers in the MANET. An attacker which records 426 messages to replay them later can only do so in the time interval 427 between the timestamp that is contained in the TIMESTAMP TLV and 428 MAX_TIMESTAMP_DIFF later. As an attacker cannot modify the content 429 of the TIMESTAMP TLV (since it does not possess the valid 430 cryptographic keys for generating valid ICV TLVs), it cannot replay 431 messages after this time interval. Within this time interval, 432 however, it is still possible to perform replay attacks. 434 11.2. Limitations 436 Since jamming is a physical layer issue, it cannot be alleviated by 437 protocols on the routing layer. This framework does not counteract 438 jamming attacks. 440 If no synchronized clocks are available in the MANET, replay attacks 441 cannot be counteracted by the framework provided by this document. 443 The framework provided by this document does not avoid or detect 444 security attacks by routers possessing the cryptographic keys that 445 are used to generate ICVs for messages. 447 This document depends on the quality of the used cipher algorithm and 448 hash function, and is as such subject the same security 449 considerations as applies to these. 451 This document relies on an out-of-band protocol or mechanism for 452 distributing keys and cryptographic parameters. The security 453 considerations of such protocol or mechanism also apply. 455 This document does also not provide a key revocation mechanism. 457 12. Acknowledgments 459 The authors would like to thank Jiazi Yi (Ecole Polytechnique) for 460 his review and comments to this document. 462 13. References 464 13.1. Normative References 466 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 467 Requirement Levels", BCP 14, RFC 2119, March 1997. 469 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 470 "Generalized MANET Packet/Message Format", RFC 5444, 471 February 2009. 473 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 474 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 475 RFC 6130, March 2011. 477 [RFC6622] Herberg, U. and T. Clausen, "Integrity Check Value and 478 Timestamp TLV Definitions for Mobile Ad Hoc Networks 479 (MANETs)", RFC 6622, May 2012. 481 13.2. Informative References 483 [NHDP-sec-threats] 484 Herberg, U., Clausen, T., and J. Yi, "Security Threats for 485 NHDP", work in 486 progress draft-ietf-manet-nhdp-sec-threats-00.txt, 487 April 2012. 489 Authors' Addresses 491 Ulrich Herberg 492 Fujitsu Laboratories of America 493 1240 E. Arques Ave. 494 Sunnyvale, CA, 94085, 495 USA 497 Email: ulrich@herberg.name 498 URI: http://www.herberg.name/ 500 Thomas Heide Clausen 501 LIX, Ecole Polytechnique 502 91128 Palaiseau Cedex, 503 France 505 Phone: +33 6 6058 9349 506 Email: T.Clausen@computer.org 507 URI: http://www.thomasclausen.org/