idnits 2.17.1 draft-herberg-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 (July 8, 2011) is 4676 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-herberg-manet-nhdp-sec-threats-00 Summary: 0 errors (**), 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 T. Clausen 4 Intended status: Experimental LIX, Ecole Polytechnique 5 Expires: January 9, 2012 July 8, 2011 7 Cryptographical Signatures in NHDP 8 draft-herberg-manet-nhdp-sec-02 10 Abstract 12 This document specifies an extension to the Neighbor Discovery 13 Protocol (NHDP) which uses cryptographic signatures in HELLO messages 14 to encounter a selection of security threats to NHDP. 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 http://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 January 9, 2012. 33 Copyright Notice 35 Copyright (c) 2011 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 4. Protocol Overview and Functioning . . . . . . . . . . . . . . 4 54 5. Transmitting a Message in NHDP . . . . . . . . . . . . . . . . 4 55 6. Signing a Message . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Processing a Message . . . . . . . . . . . . . . . . . . . . . 5 57 8. Validating a Timestamp . . . . . . . . . . . . . . . . . . . . 6 58 9. Validating a Signature . . . . . . . . . . . . . . . . . . . . 6 59 10. Parameters and Constants . . . . . . . . . . . . . . . . . . . 7 60 11. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 7 61 12. Summary of NHDP Interaction . . . . . . . . . . . . . . . . . 7 62 13. Security Threats Alleviation Analysis . . . . . . . . . . . . 8 63 13.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 13.2. Identity Spoofing . . . . . . . . . . . . . . . . . . . . 8 65 13.3. Link Spoofing . . . . . . . . . . . . . . . . . . . . . . 8 66 13.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9 67 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 16. Normative References . . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 This document describes how to use cryptographic signatures for 75 countering a selection of the security threats analyzed in 76 [NHDP-sec-threats]. It specifies the use of such signatures for 77 validating the identity of the originator of a HELLO message, the 78 validity of the content (i.e. links being advertised) of a HELLO 79 message, and the message integrity. The protection so offered 80 against the threats in [NHDP-sec-threats] is evaluated. 82 This document specifies TLVs for carrying cryptographic signatures in 83 HELLO messages using [RFC5444], and specifies extensions (as enabled 84 by [RFC6130]) to the HELLO message processing in [RFC6130]. 86 2. Terminology 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in RFC 91 2119 [RFC2119]. 93 Additionally, this document uses the terminology of [RFC5444], 94 [packetbb-sec], [RFC6130] and [NHDP-sec-threats]. 96 3. Applicability Statement 98 o [RFC6130] enables extensions to recognize additional reasons for 99 rejecting a message as malformed, and mentions security as an 100 explicit example. 102 o This document, therefore, elaborates on how this in details can be 103 done, providing a framework for signing and validating messages in 104 NHDP. 106 o Note that there is no "no one-size-fits-all", therefore this 107 document uses the containers for carrying signatures and 108 registries for cryptographic code-points as specified in 109 [packetbb-sec]. The specification should therefore be generally 110 be applicable where cryptographic signatures are thought an 111 appropriate security solution. Note that the the choice of the 112 cryptographic algorithm are to be made for each given deployment, 113 and that the choice of such is out of scope for this document. 115 o This document does not specify how to distribute cryptographic 116 keys, shared secrets, parameters for signature algorithms, etc. 118 o Note also that this document assumes that a router which is able 119 to sign messages correctly (e.g. having valid cryptographic keys), 120 is considered trusted. This document does not handle compromised 121 routers with valid keys (e.g. a router that is compromised by a 122 computer virus). 124 o This document assumes that the TLV type extension of the SIGNATURE 125 Message TLV, as defined in [packetbb-sec] is 1, i.e. that a 126 signature is composed of a cryptographic function over a hash 127 value of the message. 129 Therefore: 131 o This document is generally applicable when [RFC6130] is used, and 132 uses the [RFC5444] extension specified in [packetbb-sec]. 134 4. Protocol Overview and Functioning 136 The framework presented in this document provides two 137 functionalities: 139 o Signing a HELLO message, and 141 o Checking whether a signed incoming HELLO message is valid. 143 When a router running NHDP is about to transmit a HELLO message on an 144 interface, this extension: 146 o Specifies to calculate a digital signature of the message, and 148 o Specifies how to add that signature to a message for transmission, 149 by way of a SIGNATURE TLV. 151 The framework allows to add several signatures with different hash 152 and cryptographic functions. 154 [RFC6130] allows to reject incoming HELLO messages prior to 155 processing by NHDP for reasons such as invalid signatures. This 156 extension specifies that for each SIGNATURE TLV in the Message TLV 157 Block of that incoming message, the value of that TLV (i.e. the 158 contained signature) is verified. 160 5. Transmitting a Message in NHDP 162 HELLO messages are generated as specified in [RFC6130]. In addition, 163 each HELLO message MUST set the as well as the field as specified in [RFC5444]. Before transmission of a 165 message, it is signed as described in Section 6. 167 6. Signing a Message 169 This section specifies how to sign a message. Note that a message 170 may be signed several times using different signature algorithms. 171 The following constraints MUST be respected when signing a message: 173 o The originator address of the message MUST be included. 175 o The sequence number of the message MUST be included. 177 Optionally: 179 o A TIMESTAMP TLV (as defined in [packetbb-sec]) MAY be added to the 180 message if no such TLV is already included in the message TLV 181 block of that message. The value of the TIMESTAMP TLV is the 182 current POSIX timestamp (32-bit) of the router, and the type 183 extension is 1 (one). 185 For each signature algorithm that is used to sign the message: 187 1. All TLVs of type SIGNATURE are temporarily removed from the 188 message and stored in temporary variables. The message size is 189 recalculated accordingly, i.e. to the size of the message without 190 the SIGNATURE TLVs. 192 2. The signature value is calculated over the whole message (as 193 resulting after step 1) according to the chosen signature 194 algorithm. 196 3. A TLV of type SIGNATURE and type extension 1 is added in the 197 message TLV block. The TLV value is set to the signature 198 calculated in step 2 as well as the chosen hash and cryptographic 199 algorithms. 201 4. All other SIGNATURE TLVs that have been temporary removed, are 202 restored. 204 5. The message size is recalculated. 206 7. Processing a Message 208 NHDP specifies that 209 "On receiving a HELLO message, a router MUST first check if the 210 message is invalid for processing by this router" 212 and gives a number of conditions that will lead to a rejection of the 213 HELLO message if any of these conditions is true. The extension to 214 NHDP, specified in this document, adds the following conditions for 215 rejecting a message: 217 o The message does not include the or the field. 220 o The message contains more than one TIMESTAMP TLV. 222 o Any signature of the message is invalid as specified in Section 9. 224 o The timestamp of the message is invalid as specified in Section 8. 226 8. Validating a Timestamp 228 This section specifies how to validate a message timestamp. 230 1. If the message includes a TIMESTAMP Message TLV, and the value of 231 the TIMESTAMP TLV differs from the current POSIX time of more 232 than MAX_TIMESTAMP_DIFF, the message MUST be discarded. 234 9. Validating a Signature 236 This section specifies how to validate a message signature. 238 1. For all SIGNATURE Message TLVs: 240 A. If the TLV type extension is not 1, or if the hash function 241 and the cryptographic function defined in that TLV are known 242 to the router: goto step 2. 244 B. Otherwise goto step 1 246 2. If no signature algorithm has been recognized in step 1, the 247 message MUST be discarded. 249 3. All SIGNATURE TLVs are removed from the message, and the message 250 size is recalculated. 252 4. The signature is recalculated using the same hash function and 253 cryptographic function as indicated in the TLV, and compared with 254 the signature from the SIGNATURE TLV that has been removed in 255 step 3. 257 5. If the verification fails, the message MUST be discarded. 259 6. Otherwise: 261 A. All SIGNATURE TLVs are restored. 263 B. The message size is restored. 265 7. The message can now be processed according to [RFC6130]. 267 10. Parameters and Constants 269 This document specifies the following parameters and constants: 271 o MAX_TIMESTAMP_DIFF - The maximum age a message that is to be 272 validated may have. If the current POSIX time of the router 273 validating the message minus the timestamp indicated in the 274 TIMESTAMP TLV of the message is greater than MAX_TIMESTAMP_DIFF, 275 the message will be discarded. 277 The following constraints apply to these parameters: 279 o MAX_TIMESTAMP_DIFF > 0 281 11. Preconditions 283 Before a router is able to sign or validate messages, it must 284 initially parameterize some security settings. In particular, it 285 MUST acquire the cryptographic key(s) and any parameters of the 286 cryptographic algorithm from all other routers that are to 287 participate in the network. This document does not specify how a 288 router acquires the cryptographic keys and parameters used in the 289 MANET. 291 12. Summary of NHDP Interaction 293 When the security mechanism as specified in this document is used, 294 the following MUST be observed: 296 o NHDP must generate HELLO messages as usual. 298 o NHDP MUST allow this security mechanism access to the HELLO 299 message after its generation and prior to transmission, in order 300 that a SIGNATURE TLV can be generated and inserted, as allowed by 301 Section 16 in [RFC6130]. 303 o Any other NHDP extension which adds information to a HELLO message 304 and which wishes this added information to be included when 305 calculating the cryptographic signature MUST do so prior to the 306 HELLO message being handed off for signature generation. 308 o An incoming HELLO message MUST be processed according to this 309 specification prior to processing by [RFC6130] as allowed in 310 Section 16 in [RFC6130]. 312 o Any other NHDP extension, which has added information to a HELLO 313 message and which wishes that the HELLO message is rejected if a 314 cryptographic signature is not valid, MUST likewise process the 315 HELLO message only after its processing according to this 316 specification. 318 13. Security Threats Alleviation Analysis 320 This section analyzes which of the security threats that are detailed 321 in [NHDP-sec-threats] are alleviated by the framework presented in 322 this document. 324 13.1. Jamming 326 Since jamming is a physical layer issue, it cannot be alleviated by 327 protocols on the routing layer. This framework does not counteract 328 jamming attacks, therefore. 330 13.2. Identity Spoofing 332 As only routers possessing valid cryptographic keys are able to 333 correctly sig HELLO messages, identity spoofing is counteracted. If 334 a router does not have access to valid keys or does not sign messages 335 at all, it is not able to create HELLOs that are processed by 336 neighbor routers. Such wrongly signed or unsigned messages are 337 rejected by receiving routers as described in Section 9. 339 13.3. Link Spoofing 341 Link spoofing is counteracted by the framework specified in this 342 document, with the same argument as in Section 13.2. A router 343 without access to valid cryptographic keys cannot sign the message 344 correctly, and therefore the message will be rejected by any 345 receiving routers. Hence, all links postulated by an attacker are 346 ignored. 348 13.4. Replay Attack 350 Replay attacks are only counteracted if TIMESTAMP TLVs are included 351 in HELLO messages. This is optional, and depends on synchronized 352 clocks of all routers in the MANET. An attacker which records 353 messages to replay them later can only do so in the time interval 354 between the timestamp that is contained in the TIMESTAMP TLV and 355 MAX_TIMESTAMP_DIFF seconds later. As an attacker cannot modify the 356 content of the TIMESTAMP TLV (since it does not possess the valid 357 cryptographic keys), it cannot replay messages after this time 358 interval. Within this time interval, however, it is still possible 359 to replay attacks. 361 14. IANA Considerations 363 This document has no actions for IANA. 365 15. Security Considerations 367 This document specifies a protocol extension to NHDP which allows to 368 alleviate some of the security threats of NHDP analyzed in 369 [NHDP-sec-threats]. 371 If no synchronized clocks are available in the MANET, replay attacks 372 cannot be counteracted by this framework. 374 This framework does not avoid or detect security attacks by routers 375 possessing the cryptographic keys that is used to sign messages. 377 This specification depends on the quality of the used signature 378 algorithm and provides as such the same security considerations as 379 the hash function and the cipher algorithm. 381 This specification relies on an out-of-band protocol to distribute 382 keys and parameters. The security considerations of that protocol 383 apply. 385 This specification does not provide a key revocation mechanism. 387 16. Normative References 389 [NHDP-sec-threats] 390 Herberg, U. and T. Clausen, "Security Threats for NHDP", 391 work in 392 progress draft-herberg-manet-nhdp-sec-threats-00.txt, 393 November 2009. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, March 1997. 398 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 399 "Generalized MANET Packet/Message Format", RFC 5444, 400 February 2009. 402 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 403 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 404 RFC 6130, March 2011. 406 [packetbb-sec] 407 Herberg, U. and T. Clausen, "MANET Cryptographical 408 Signature TLV Definition", work in 409 progress draft-ietf-manet-packetbb-sec-04.txt, July 2011. 411 Authors' Addresses 413 Ulrich Herberg 414 LIX, Ecole Polytechnique 415 91128 Palaiseau Cedex, 416 France 418 Email: ulrich@herberg.name 419 URI: http://www.herberg.name/ 421 Thomas Heide Clausen 422 LIX, Ecole Polytechnique 423 91128 Palaiseau Cedex, 424 France 426 Phone: +33 6 6058 9349 427 Email: T.Clausen@computer.org 428 URI: http://www.thomasclausen.org/