idnits 2.17.1 draft-ietf-manet-nhdp-olsrv2-sec-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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2013) is 4054 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) == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-17 == Outdated reference: A later version (-02) exists of draft-herberg-manet-rfc6622-bis-00 Summary: 0 errors (**), 0 flaws (~~), 4 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 Updates: RFC6130 (if approved) C. Dearlove 5 Intended status: Standards Track BAE Systems ATC 6 Expires: September 23, 2013 T. Clausen 7 LIX, Ecole Polytechnique 8 March 22, 2013 10 Integrity Protection for Control Messages in NHDP and OLSRv2 11 draft-ietf-manet-nhdp-olsrv2-sec-00 13 Abstract 15 This document specifies integrity and replay protection for required 16 implementation in the MANET Neighborhood Discovery Protocol (NHDP) 17 and the Optimized Link State Routing Protocol version 2 (OLSRv2). 18 This document specifies how an included integrity check value (ICV) 19 and a timestamp TLV, defined in RFC6622bis, are used by NHDP and 20 OLSRv2 for countering a number of security threats. The ICV TLV uses 21 a SHA-256 based HMAC and a single shared secret key. The timestamp 22 TLV is based on POSIX time, assuming router synchronization. The 23 mechanism in this specification can also be used for other MANET 24 protocols using RFC5444. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 23, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 63 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 6 64 5. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 6. Message Generation and Processing . . . . . . . . . . . . . . 8 66 6.1. Message Content . . . . . . . . . . . . . . . . . . . . . 8 67 6.2. Message Generation . . . . . . . . . . . . . . . . . . . . 8 68 6.3. Message Processing . . . . . . . . . . . . . . . . . . . . 9 69 6.3.1. Invalidating a Message Based on Timestamp . . . . . . 10 70 6.3.2. Invalidating a Message Based on Integrity Check . . . 10 71 7. Provisioning of Routers . . . . . . . . . . . . . . . . . . . 11 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 9.1. Alleviated Attacks . . . . . . . . . . . . . . . . . . . . 11 75 9.1.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 76 9.1.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 77 9.1.3. Replay Attack . . . . . . . . . . . . . . . . . . . . 11 78 9.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 12 79 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 This specification defines a framework of security mechanisms that 85 must be included in conforming implementations of the Neighborhood 86 Discovery Protocol (NHDP) [RFC6130] and the Optimized Link State 87 Routing Protocol version 2 (OLSRv2) [OLSRv2] for Mobile Ad hoc 88 NETworks (MANETs). A deployment of these protocols may choose to 89 employ alternative(s) to these mechanisms, in particular it may 90 choose to protect packets rather than messages, it may choose to use 91 an alternative integrity check value (ICV) with preferred properties, 92 or it may use an alternative timestamp. A deployment may choose to 93 use no such security mechanisms, but this is not recommended. 95 The mechanisms specified are the use of an ICV for protection of the 96 protocols' control messages, and the use of timestamps in those 97 messages to prevent replay attacks. Both use the TLV mechanism 98 specified in [RFC5444] to add this information to the messages. 99 These ICV and timestamp TLVs are defined in [RFC6622bis]. Different 100 ICV TLVs are used for HELLO messages in NHDP and TC messages in 101 OLSRv2, the former also protecting the source address of the IP 102 datagram that contains the HELLO message, because the IP datagram 103 source address is used by NHDP to determine the address of a neighbor 104 interface, and is not necessarily otherwise contained in the HELLO 105 message. 107 The mechanism specified in this document must insert itself between 108 NHDP's and OLSRv2's message processing/generation and the [RFC5444] 109 packet parsing/generation, as illustrated in Figure 1. 111 | | 112 Incoming | /|\ Outgoing 113 packet \|/ | packet 114 | | 115 +--------------------------------+ 116 | | 117 | RFC5444 packet | 118 | parsing / generation | 119 | | 120 +--------------------------------+ 121 | | 122 Messages | /|\ Messages with 123 \|/ | added TLVs 124 | | 125 D +--------------------------------+ 126 R /__________________ | | 127 O \ Messages | This specification | 128 P (failed check) | | 129 +--------------------------------+ 130 | | 131 Messages | /|\ Messages 132 (passed check) \|/ | 133 | | 134 +--------------------------------+ 135 | | 136 | NHDP/OLSRv2 message | 137 | processing / generation | 138 | | 139 +--------------------------------+ 141 Figure 1: Relationship with RFC5444 and NHDP/OLSRv2 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in 148 [RFC2119]. 150 Additionally, this document uses the terminology of [RFC5444], 151 [RFC6130], [OLSRv2], and [RFC6622bis]. 153 3. Applicability Statement 155 [RFC6130] and [OLSRv2] enable extensions to recognize additional 156 reasons for rejecting a message as "badly formed and therefore 157 invalid for processing", and mention security (integrity protection) 158 as an explicit example. This document specifies a framework that 159 provides this functionality. 161 Implementations of [RFC6130] and [OLSRv2] MUST include this 162 framework, and deployments of [RFC6130] and [OLSRv2] SHOULD use this 163 framework, except for when a different security mechanism is more 164 appropriate. 166 The applicability of this framework is determined by its 167 characteristics, which are that it: 169 o Specifies a security framework that is required to be included in 170 conforming implementations of [RFC6130] and [OLSRv2]. 172 o Specifies an association of ICVs with messages, and for using 173 missing or invalid ICVs as such an additional reason for rejecting 174 a message as "badly formed and therefore invalid for processing". 176 o Specifies the implementation of an ICV TLV, defined in 177 [RFC6622bis], using a SHA-256 based HMAC applied to the 178 appropriate message contents (and for HELLO messages also 179 including the IP datagram source address). Deployments of 180 [RFC6130] and [OLSRv2] using this framework should use the HMAC/ 181 SHA-256 ICV TLV, but may use different algorithms if more 182 appropriate in a deployment. An implementation may also use more 183 than one ICV TLV in a message as long as they each use a different 184 algorithm to calculate the ICV. 186 o Specifies the implementation of a TIMESTAMP TLV, defined in 187 [RFC6622bis], to provide message replay protection. Deployments 188 of [RFC6130] and [OLSRv2] using this framework SHOULD use a POSIX 189 time based timestamp, if all routers can be sufficiently 190 synchronized. 192 o Assumes that a router that is able to generate correct integrity 193 check values is considered trusted. 195 This framework does not: 197 o Specify how to distribute cryptographic material (shared secret 198 key). 200 o Specify how to detect compromised routers with valid keys. 202 o Specify how to handle (revoke) compromised routers with valid 203 keys. 205 4. Protocol Overview and Functioning 207 The framework specified in this document provides the following 208 functionalities for use with messages owned by [RFC6130] and 209 [OLSRv2]: 211 o Generation of ICV TLVs (as defined in [RFC6622bis]) for inclusion 212 in an outgoing message. An implementation of [RFC6130] and 213 [OLSRv2] may use more than one ICV TLV in a message, even with the 214 same type extension, but these ICV TLVs MUST each use a different 215 algorithm to calculate the ICV, e.g., with different hash and/or 216 cryptographic functions when using type extension 1 or 2. An 217 implementation of [RFC6130] and [OLSRv2] must at least be able to 218 generate an ICV TLV using HMAC/SHA-256 and a single secret key 219 shared by all routers. 221 o Generation of TIMESTAMP TLVs (as defined in [RFC6622bis]) for 222 inclusion in an outgoing message. An implementation of [RFC6130] 223 and [OLSRv2] that is able to synchronize routers, must at least be 224 able to generate a TIMESTAMP TLV using POSIX time. 226 o Verification of ICV TLVs contained in a message, in order to 227 determine if this message MUST be rejected as "badly formed and 228 therefore invalid for processing" [RFC6130] [OLSRv2]. An 229 implementation of [RFC6130] and [OLSRv2] must at least be able to 230 verify an ICV TLV using HMAC/SHA-256 and a single secret key 231 shared by all routers. 233 o Verification of a TIMESTAMP TLV (as defined in [RFC6622bis]) 234 contained in a message, in order to determine if this message MUST 235 be rejected as "badly formed and therefore invalid for processing" 236 [RFC6130] [OLSRv2]. An implementation of [RFC6130] and [OLSRv2] 237 that is able to synchronize routers, must at least be able to 238 verify a TIMESTAMP TLV using POSIX time. 240 ICV Packet TLVs (as defined in [RFC6622bis]) may be used by a 241 deployment of the multiplexing process defined in [RFC5444], either 242 as well as, or instead of, the protection of the NHDP and OLSRv2 243 messages. (Note that in the case of NHDP, the packet protection is 244 equally good, and also protects the packet header. In the case of 245 OLSRv2, the packet protection has different properties than the 246 message protection, especially for some forms of ICV. When packets 247 contain more than one message, the packet protection has lower 248 overheads in space and computation time.) 250 When a router generates a message on a MANET interface, this 251 framework: 253 o Specifies how to calculate an integrity check value for the 254 message. 256 o Specifies how to include that integrity check value using an ICV 257 Message TLV. 259 [RFC6130] and [OLSRv2] allow for rejecting incoming messages prior to 260 processing by NHDP or OLSRv2. This framework specifies that a 261 message must be rejected if the ICV Message TLV is absent, or its 262 value cannot be verified. 264 5. Parameters 266 This following router parameters is specified for use by the two 267 protocols; the first is required only by NHDP, but may be visible to 268 OLSRv2, the second is required only by OLSRv2: 270 o MAX_HELLO_TIMESTAMP_DIFF - The maximum age that a HELLO message to 271 be validated may have. If the current POSIX time of the router 272 validating the HELLO message, minus the timestamp indicated in the 273 TIMESTAMP TLV of the HELLO message, is greater than 274 MAX_HELLO_TIMESTAMP_DIFF, the HELLO message MUST be silently 275 discarded. 277 o MAX_TC_TIMESTAMP_DIFF - The maximum age that a TC message to be 278 validated may have. If the current POSIX time of the router 279 validating the TC message, minus the timestamp indicated in the 280 TIMESTAMP TLV of the TC message, is greater than 281 MAX_TC_TIMESTAMP_DIFF, the TC message MUST be silently discarded. 283 The following constraints apply to these parameters: 285 o MAX_HELLO_TIMESTAMP_DIFF > 0 287 o MAX_HELLO_TIMESTAMP_DIFF < REFRESH_INTERVAL 289 o MAX_TC_TIMESTAMP_DIFF > 0 291 o MAX_TC_TIMESTAMP_DIFF < T_HOLD_TIME 293 The second and fourth of those constraints assume ideal 294 synchronization. These bounds MAY be relaxed to allow for expected 295 timing differences between routers (between neighboring routers for 296 MAX_HELLO_TIMESTAMP_DIFF). However it should also be noted that, in 297 the ideal case, the parameters SHOULD be significantly less than 298 those bounds. 300 6. Message Generation and Processing 302 This section specifies how messages are generated and processed by 303 [RFC6130] and [OLSRv2] when using this framework. 305 6.1. Message Content 307 Messages MUST have the content specified in [RFC6130] and [OLSRv2] 308 respectively. In addition, in order to conform to this framework, 309 each message MUST contain: 311 o At least one ICV Message TLV (as specified in [RFC6622bis]), 312 generated according to Section 6.2. Implementations of [RFC6130] 313 and [OLSRv2] MUST support the following version of the ICV TLV, 314 but other versions MAY be used instead, or in addition, in a 315 deployment, if more appropriate: 317 * For TC messages: 319 + type-extension := 1 321 * For HELLO messages: 323 + type-extension := 2 325 * hash-function := 3 (SHA-256) 327 * cryptographic-function := 3 (HMAC) 329 A message MAY contain several ICV Message TLVs. 331 o At least one TIMESTAMP Message TLV (as specified in 332 [RFC6622bis])"/>), generated according to Section 6.2. 333 Implementations of [RFC6130] and [OLSRv2] using this framework 334 MUST support the following version of the TIMESTAMP TLV, but other 335 versions MAY be used instead, or in addition, in a deployment, if 336 more appropriate: 338 * type-extension := 1 340 6.2. Message Generation 342 After message generation (Section 11.1 of [RFC6130] and Section 16.1. 343 of [OLSRv2]) and before message transmission (Section 11.2 of 344 [RFC6130] and Section 16.2 of [OLSRv2]), the additional TLVs 345 specified in Section 6.1 MUST (unless already present) be added to an 346 outgoing message when using this framework. 348 The following processing steps MUST be performed for a cryptographic 349 algorithm that is used for generating an ICV for a message: 351 1. All ICV TLVs (if any) are temporarily removed from the message. 352 Any temporarily removed ICV TLVs MUST be stored, in order to be 353 reinserted into the message in step 5. The message size is 354 updated accordingly. 356 2. and , if present, are temporarily 357 set to 0. 359 3. A TLV of type TIMESTAMP, as specified in Section 6.1, is added to 360 the Message TLV block. The message size is updated accordingly. 362 4. A TLV of type ICV, as specified in Section 6.1, is added to the 363 Message TLV block. The message size is updated accordingly. 365 5. All ICV TLVs that were temporary removed in step 1, are restored. 366 The message size is updated accordingly. 368 6. and , if present, are restored to 369 their previous values. 371 6.3. Message Processing 373 Both [RFC6130] and [OLSRv2] specify that: 375 "On receiving a ... message, a router MUST first check if the 376 message is invalid for processing by this router" 378 [RFC6130] and [OLSRv2] proceed to give a number of conditions that, 379 each, will lead to a rejection of the message as "badly formed and 380 therefore invalid for processing". When using a single timestamp 381 version, and a single ICV algorithm, the following conditions to that 382 list, each of which, if true, MUST cause NHDP or OLSRv2 (as 383 appropriate) to consider the message as invalid for processing when 384 using this framework: 386 1. The Message TLV Block of the message does not contain exactly one 387 TIMESTAMP TLV of the selected version. This version 388 specification includes the type extension. (The Message TLV 389 Block may also contain TIMESTAMP TLVs of other versions.) 391 2. The Message TLV block does not contain exactly one ICV TLV using 392 the selected algorithm. This algorithm specification includes 393 the type extension, and for type extensions 1 and 2, the hash 394 function and cryptographic function. (The Message TLV Block may 395 also contain ICV TLVs using other algorithms.) 397 3. Validation of the identified (in step 1) TIMESTAMP TLV in the 398 Message TLV block of the message fails, as according to 399 Section 6.3.1. 401 4. Validation of the identified (in step 2) ICV TLVs in the Message 402 TLV block of the message fails, as according to Section 6.3.2. 404 An implementation MAY check the existence of, and verify, either 405 alternative TIMESTAMP and/or ICV TLVs, or more than one TIMESTAMP 406 and/or ICV TLVs. 408 6.3.1. Invalidating a Message Based on Timestamp 410 For a TIMESTAMP Message TLV with type extension 1 (POSIX time) 411 identified as described in Section 6.2: 413 1. If the current POSIX time minus the value of that TIMESTAMP TLV 414 is greater than MAX_HELLO_TIMESTAMP_DIFF (for a HELLO message) or 415 MAX_TC_TIMESTAMP_DIFF (for a TC message) then the message 416 validation fails. 418 2. Otherwise, the message validation succeeds. 420 If a deployment chooses to use a different type extension from 1, 421 appropriate measures MUST be taken to verify freshness of the 422 message. 424 6.3.2. Invalidating a Message Based on Integrity Check 426 For an ICV Message TLV identified as described in Section 6.2: 428 1. All ICV Message TLVs (including the identified ICV Message TLV) 429 are temporarily removed from the message, and the message size is 430 updated accordingly. 432 2. The message's and fields are 433 temporarily set to 0. 435 3. Calculate the integrity check value for the parameters specified 436 in the identified ICV Message TLV, as specified in [RFC6622bis]. 438 4. If this integrity check value differs from the value of in the ICV Message TLV, then the message validation fails. 441 5. Otherwise, the message validation succeeds. The message's and fields are restored to their 443 previous value, and the ICV Message TLVs are returned to the 444 message, whose size is updated accordingly. 446 7. Provisioning of Routers 448 Before a router is able to generate ICVs or validate messages, it 449 MUST acquire the single shared secret key that is to be used by all 450 routers that are to participate in the network. This specification 451 does not define how a router acquires this secret key. 453 8. IANA Considerations 455 This document has no actions for IANA. 457 9. Security Considerations 459 This document specifies a security framework for use with NHDP and 460 OLSRv2 that allows for alleviating several security threats. 462 9.1. Alleviated Attacks 464 This section briefly summarizes security threats that are alleviated 465 by the framework presented in this document. 467 9.1.1. Identity Spoofing 469 As only routers possessing the shared secret key are able to add a 470 valid ICV TLV to a message, identity spoofing is countered. 472 9.1.2. Link Spoofing 474 Link spoofing is countered by the framework specified in this 475 document, using the same argument as in Section 9.1.1. 477 9.1.3. Replay Attack 479 Replay attacks are partly counteracted by the framework specified in 480 this document, but this depends on synchronized clocks of all routers 481 in the MANET. An attacker that records messages to replay them later 482 can only do so in the selected time interval after the timestamp that 483 is contained in message. As an attacker cannot modify the content of 484 this timestamp (as it is protected by the identity check value), an 485 attacker cannot replay messages after this time. Within this time 486 interval it is still possible to perform replay attacks, however the 487 limits on the time interval are specified so that this will have a 488 limited effect on the operation of the protocol. 490 9.2. Limitations 492 If no synchronized clocks are available in the MANET, replay attacks 493 cannot be countered by the framework provided by this document. An 494 alternative version of the TIMESTAMP TLV defined in [RFC6622bis], 495 with a monotonic sequence number, may have some partial value in this 496 case, but will necessitate adding state to record observed message 497 sequence number information. 499 The framework provided by this document does not avoid or detect 500 security attacks by routers possessing the shared secret key that is 501 used to generate integrity check values for messages. 503 This framework relies on an out-of-band protocol or mechanism for 504 distributing the shared secret key (and if an alternative integrity 505 check value is used, any additional cryptographic parameters). 507 This framework does not provide a key revocation mechanism. 509 10. Normative References 511 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 512 "The Optimized Link State Routing Protocol version 2", 513 draft-ietf-manet-olsrv2-17 (work in progress), 514 October 2012. 516 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 517 Requirement Levels", BCP 14, RFC 2119, March 1997. 519 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 520 "Generalized MANET Packet/Message Format", RFC 5444, 521 February 2009. 523 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc 524 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 525 RFC 6130, April 2011. 527 [RFC6622bis] 528 Herberg, U., Clausen, T., and C. Dearlove, "Integrity 529 Check Value and Timestamp TLV Definitions for Mobile Ad 530 Hoc Networks (MANETs)", Internet 531 Draft draft-herberg-manet-rfc6622-bis-00, February 2013. 533 Authors' Addresses 535 Ulrich Herberg 536 Fujitsu Laboratories of America 537 1240 E. Arques Ave. 538 Sunnyvale, CA, 94085, 539 USA 541 Email: ulrich@herberg.name 542 URI: http://www.herberg.name/ 544 Christopher Dearlove 545 BAE Systems ATC 547 Phone: +44 1245 242194 548 Email: chris.dearlove@baesystems.com 549 URI: http://www.baesystems.com/ 551 Thomas Heide Clausen 552 LIX, Ecole Polytechnique 553 91128 Palaiseau Cedex, 554 France 556 Phone: +33 6 6058 9349 557 Email: T.Clausen@computer.org 558 URI: http://www.thomasclausen.org/