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