idnits 2.17.1 draft-ietf-manet-packetbb-sec-09.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 6, 2012) is 4435 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) -- Possible downref: Non-RFC (?) normative reference: ref. '3DES' -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Obsolete normative reference: RFC 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'DSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ECDSA' -- Possible downref: Non-RFC (?) normative reference: ref. 'POSIX' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4330 (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHS' == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-13 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). 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 7, 2012 LIX, Ecole Polytechnique 6 March 6, 2012 8 Integrity Check Value and Timestamp TLV Definitions for MANETs 9 draft-ietf-manet-packetbb-sec-09 11 Abstract 13 This document describes general and flexible TLVs for representing 14 cryptographic integrity check values (ICV) (i.e. digital signatures 15 or MACs) as well as timestamps, using the generalized MANET packet/ 16 message format defined in RFC 5444. It defines two Packet TLVs, two 17 Message TLVs, and two Address Block TLVs, for affixing ICVs and 18 timestamps to a packet, message and address, respectively. 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 September 7, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 57 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4 58 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 5 59 6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 6 60 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 6 61 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . . . . 7 63 8.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 7 64 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 9.1. Message ICV TLV . . . . . . . . . . . . . . . . . . . . . 7 66 9.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 8 67 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Address Block ICV TLV . . . . . . . . . . . . . . . . . . 8 69 10.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 9 70 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. ICV: Cryptographic Function over a Hash Value . . . . . . . . 9 72 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 9 73 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 74 12.2. Considerations for Calculating the ICV . . . . . . . . . . 11 75 12.2.1. Packet ICV TLV . . . . . . . . . . . . . . . . . . . 11 76 12.2.2. Message ICV TLV . . . . . . . . . . . . . . . . . . . 11 77 12.2.3. Address Block ICV TLV . . . . . . . . . . . . . . . . 11 78 12.3. Example of a Message including an ICV . . . . . . . . . . 11 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 13 81 13.2. Packet TLV Type Registrations . . . . . . . . . . . . . . 14 82 13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 15 83 13.4. Address Block TLV Type Registrations . . . . . . . . . . . 16 84 13.5. Hash Function . . . . . . . . . . . . . . . . . . . . . . 17 85 13.6. Cryptographic Algorithm . . . . . . . . . . . . . . . . . 17 86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 18 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 16.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 16.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 93 1. Introduction 95 This document specifies: 97 o Two TLVs for carrying integrity check values (ICV) and timestamps 98 in packets, messages, and address blocks as defined by [RFC5444], 100 o A generic framework for ICVs, accounting (for Message TLVs) for 101 mutable message header fields ( and ), where these fields are present in messages. 104 This document sets up IANA registries for recording code points for 105 hash function and ICV calculation, respectively. 107 Moreover, this document defines, in Section 12: 109 o One common method for generating ICVs as a cryptographic function, 110 calculated over the hash value of the content to be signed. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in 117 [RFC2119]. 119 This document uses the terminology and notation defined in [RFC5444]. 120 In particular, the following TLV fields from [RFC5444] are used in 121 this specification: 123 - hop limit of a message, as specified in Section 124 5.2 of [RFC5444]. 126 - hop count of a message, as specified in Section 127 5.2 of [RFC5444]. 129 - length of a TLV in octets, as specified in Section 5.4.1 130 of [RFC5444]. 132 3. Applicability Statement 134 MANET routing protocols using the format defined in [RFC5444] are 135 accorded the ability to carry additional information in control 136 messages and packets, through inclusion of TLVs. Information so 137 included MAY be used by a MANET routing protocol, or by an extension 138 of a MANET routing protocol, according to its specification. 140 This document specifies how to include an ICV for a packet, a 141 message, and addresses in address blocks within a message, by way of 142 such TLVs. This document also specifies how to treat "mutable" 143 fields, specifically the and fields, 144 if present in the message header when calculating ICVs, such that the 145 resulting ICV can be correctly verified by any recipient, and how to 146 include this ICV. 148 This document describes a generic framework for creating ICVs, and 149 how to include these ICVs in TLVs. In Section 12, an example method 150 for calculating such ICVs is given, using a cryptographic function 151 over the hash value of the content to be signed. 153 4. Security Architecture 155 Basic MANET routing protocol specifications are often "oblivious to 156 security", however have a clause allowing a control message to be 157 rejected as "badly formed" or "insecure" prior to it being processed 158 or forwarded. MANET routing protocols such as [RFC6130] and [OLSRv2] 159 recognize external reasons (such as failure to verify an ICV) for 160 rejecting a message, and therefore "invalid for processing". This 161 architecture is a result of the observation that with respect to 162 security in MANETs, "one size rarely fits all" and that MANET routing 163 protocol deployment domains have varying security requirements 164 ranging from "unbreakable" to "virtually none". The virtue of this 165 approach is that MANET routing protocol specifications (and 166 implementations) can remain "generic", with extensions providing 167 proper deployment-domain specific security mechanisms. 169 The MANET routing protocol "security architecture", in which this 170 specification situates itself, can therefore be summarized as 171 follows: 173 o Security-oblivious MANET routing protocol specifications, with a 174 clause allowing an extension to reject a message (prior to 175 processing/forwarding) as "badly formed" or "insecure". 177 o MANET routing protocol security extensions, rejecting messages as 178 "badly formed" or "insecure", as appropriate for a given 179 deployment-domain specific security requirement. 181 o Code-points and an exchange format for information, necessary for 182 specification of such MANET routing protocol security extensions. 184 This document addresses the last of these issues, by specifying a 185 common exchange format for cryptographic ICVs, making reservations 186 from within the Packet TLV, Message TLV, and Address Block TLV 187 registries of [RFC5444], to be used (and shared) among MANET routing 188 protocol security extensions. 190 For the specific decomposition of an ICV into a cryptographic 191 function over a hash value, specified in Section 12, this document 192 establishes two IANA registries for code-points for hash functions 193 and cryptographic functions adhering to [RFC5444]. 195 With respect to [RFC5444], this document: 197 o Is intended to be used in the non-normative, but intended, mode of 198 use described in Appendix B of [RFC5444]. 200 o Is a specific example of the Security Considerations section of 201 [RFC5444] (the authentication part). 203 5. Overview and Functioning 205 This document specifies a syntactical representation of security 206 related information for use with [RFC5444] addresses, messages, and 207 packets, as well as establishes IANA registrations and registries. 209 Moreover, this document provides guidelines for how MANET routing 210 protocols, and MANET routing protocol extensions, using this 211 specification, should treat ICV and Timestamp TLVs, and mutable 212 fields in messages. This specification does not represent a stand- 213 alone protocol; MANET routing protocols and MANET routing protocol 214 extensions, using this specification, MUST provide instructions as to 215 how to handle packets, messages and addresses with security 216 information, associated as specified in this document. 218 This document requests assignment of TLV types from the registries 219 defined for Packet, Message and Address Block TLVs in [RFC5444]. 220 When a TLV type is assigned from one of these registries, a registry 221 for "Type Extensions" for that TLV type is created by IANA. This 222 document utilizes these "Type Extension" registries so created, in 223 order to specify internal structure (and accompanying processing) of 224 the field of a TLV. 226 For example, and as defined in this document, an ICV TLV with Type 227 Extension = 0 specifies that the field has no pre-defined 228 internal structure, but is simply a sequence of octets. An ICV TLV 229 with Type Extension = 1 specifies that the field has a pre- 230 defined internal structure, and defines its interpretation 231 (specifically, the field consists of a cryptographic 232 operation over a hash value, with fields indicating which hash 233 function and cryptographic operation has been used, specified in 234 Section 12). 236 Other documents can request assignments for other Type Extensions, 237 and MUST, if so, specify their internal structure (if any) and 238 interpretation. 240 6. General ICV TLV Structure 242 The value of the ICV TLV is: 244 := 246 where: 248 is a field, of octets, which contains the 249 information, to be interpreted by the ICV verification process, as 250 specified by the Type Extension. 252 Note that this does not stipulate how to calculate the , 253 nor the internal structure hereof, if any; such MUST be specified by 254 way of the Type Extension for the ICV TLV type, see Section 13. This 255 document specifies two such type-extensions, for ICVs without pre- 256 defined structures, and for ICVs constructed by way of a 257 cryptographic operation over a hash-value. 259 7. General Timestamp TLV Structure 261 The value of the Timestamp TLV is: 263 := 265 where: 267 is an unsigned integer field, of length , which 268 contains the timestamp. 270 Note that this does not stipulate how to calculate the , nor the internal structure hereof, if any; such MUST be 272 specified by way of the Type Extension for the TIMESTAMP TLV type, 273 see Section 13. 275 A timestamp is essentially "freshness information". As such, its 276 setting and interpretation is to be determined by the MANET routing 277 protocol, or MANET routing protocol extension, that uses the 278 timestamp, and can, e.g., correspond to a UNIX-timestamp, GPS 279 timestamp or a simple sequence number. 281 8. Packet TLVs 283 Two Packet TLVs are defined, for including the cryptographic ICV of a 284 packet, and for including the timestamp indicating the time at which 285 the cryptographic ICV was calculated. 287 8.1. Packet ICV TLV 289 A Packet ICV TLV is an example of an ICV TLV as described in 290 Section 6. 292 The following considerations apply: 294 o As packets defined in [RFC5444] are never forwarded by routers, no 295 special considerations are required regarding mutable fields (e.g. 296 and ), if present, when calculating 297 the ICV. 299 o Any Packet ICV TLVs already present in the Packet TLV block MUST 300 be removed before calculating the ICV, and the Packet TLV block 301 size MUST be recalculated accordingly. Removed ICV TLVs MUST be 302 restored after having calculated the ICV value. 304 The rationale for removing any Packet ICV TLV already present prior 305 to calculating the ICV is that several ICVs may be added to the same 306 packet, e.g., using different ICV functions. 308 8.2. Packet TIMESTAMP TLV 310 A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described 311 in Section 7. If a packet contains a TIMESTAMP TLV and an ICV TLV, 312 the TIMESTAMP TLV SHOULD be added to the packet before any ICV TLV, 313 in order that it be included in the calculation of the ICV. 315 9. Message TLVs 317 Two Message TLVs are defined, for including the cryptographic ICV of 318 a message, and for including the timestamp indicating the time at 319 which the cryptographic ICV was calculated. 321 9.1. Message ICV TLV 323 A Message ICV TLV is an example of an ICV TLV as described in 324 Section 6. When determining the for a message, the 325 following considerations MUST be applied: 327 o The fields and , if present, MUST 328 both be assumed to have the value 0 (zero) when calculating the 329 ICV. 331 o Any Message ICV TLVs already present in the Message TLV block MUST 332 be removed before calculating the ICV, and the message size as 333 well as the Message TLV block size MUST be recalculated 334 accordingly. Removed ICV TLVs MUST be restored after having 335 calculated the ICV value. 337 The rationale for removing any Message ICV TLV already present prior 338 to calculating the ICV is that several ICVs may be added to the same 339 message, e.g., using different ICV functions. 341 9.2. Message TIMESTAMP TLV 343 A Message TIMESTAMP TLV is an example of a Timestamp TLV as described 344 in Section 7. If a message contains a TIMESTAMP TLV and an ICV TLV, 345 the TIMESTAMP TLV SHOULD be added to the message before the ICV TLV, 346 in order that it be included in the calculation of the ICV. 348 10. Address Block TLVs 350 Two Address Block TLVs are defined, for associating a cryptographic 351 ICV to an address, and for including the timestamp indicating the 352 time at which the cryptographic ICV was calculated. 354 10.1. Address Block ICV TLV 356 An Address Block ICV TLV is an example of an ICV TLV as described in 357 Section 6. The ICV is calculated over the address, concatenated with 358 any other values, for example, any other Address Block TLV 359 fields, that is associated with that address. A MANET routing 360 protocol or MANET routing protocol extension using Address Block ICV 361 TLVs MUST specify how to include any such concatenated attribute of 362 the address in the verification process of the ICV. When determining 363 the for an address, the following consideration MUST be 364 applied: 366 o If other TLV values are concatenated with the address for 367 calculating the ICV, these TLVs MUST NOT be Address Block ICV TLVs 368 already associated with the address. 370 The rationale for not concatenating the address with any ICV TLV 371 values already associated with the address when calculating the ICV 372 is that several ICVs may be added to the same address, e.g., using 373 different ICV functions. 375 10.2. Address Block TIMESTAMP TLV 377 An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as 378 described in Section 7. If both a TIMESTAMP TLV and an ICV TLV are 379 associated with an address, the TIMESTAMP TLV MUST be covered 380 when calculating the value of the ICV to be contained in the ICV TLV 381 value (i.e. concatenated with the associated address and any other 382 values as described in Section 10.1). 384 11. ICV: Basic 386 The basic ICV, represented by way of an ICV TLV with Type Extension = 387 0, is a simple bit-field containing the cryptographic ICV. This 388 assumes that the mechanism stipulating how ICVs are calculated and 389 verified is established outside of this specification, e.g., by way 390 of administrative configuration or external out-of-band signaling. 391 Thus, the for when using Type Extension = 0 is: 393 := 395 where: 397 is an unsigned integer field, of length , which 398 contains the cryptographic ICV. 400 12. ICV: Cryptographic Function over a Hash Value 402 One common way of calculating an ICV is applying a cryptographic 403 function on a hash value of the content. This decomposition is 404 specified in the following, using a Type Extension = 1 in the ICV 405 TLVs. 407 12.1. General ICV TLV Structure 409 The following data structure allows representation of a cryptographic 410 ICV, including specification of the appropriate hash function and 411 cryptographic function used for calculating the ICV: 413 := 414 415 416 418 where: 420 is an 8-bit unsigned integer field specifying the 421 hash function. 423 is an 8-bit unsigned integer field 424 specifying the cryptographic function. 426 is an 8-bit unsigned integer field specifying the 427 length of the field in number of octets. The value 0x00 428 is reserved for using a pre-installed, shared key. 430 is a field specifying the key identifier of the key that 431 was used to sign the message, which allows unique identification 432 of different keys with the same originator. It is the 433 responsibility of each key originator to make sure that actively 434 used keys that it issues have distinct key identifiers. If equals to 0x00, the field is not contained in 436 the TLV, and a pre-installed, shared key is used. 438 is an unsigned integer field, whose length is - 439 3 - , and which contains the cryptographic ICV. 441 The version of this TLV, specified in this section, assumes that 442 calculating the ICV can be decomposed into: 444 ICV-value = cryptographic-function(hash-function(content)) 446 The hash function and the cryptographic function correspond to the 447 entries in two IANA registries, set up by this specification in 448 Section 13. 450 12.1.1. Rationale 452 The rationale for separating the hash function and the cryptographic 453 function into two octets instead of having all combinations in a 454 single octet - possibly as TLV type extension - is that adding 455 further hash functions or cryptographic functions in the future may 456 lead to a non-contiguous number space. 458 The rationale for not including a field that lists parameters of the 459 cryptographic ICV in the TLV is that, before being able to validate a 460 cryptographic ICV, routers have to exchange or acquire keys (e.g. 461 public keys). Any additional parameters can be provided together 462 with the keys in that bootstrap process. It is therefore not 463 necessary, and would even entail an extra overhead, to transmit the 464 parameters within every message. One implicitly available parameter 465 is the length of the ICV, which is - 3 - , 466 and which depends on the choice of the cryptographic function. 468 12.2. Considerations for Calculating the ICV 470 In the following, considerations are listed, which MUST be applied 471 when calculating the ICV for Packet, Message and Address ICV TLVs, 472 respectively. 474 12.2.1. Packet ICV TLV 476 When determining the for a Packet, the ICV is calculated 477 over the fields , , and - if present - (in that order), concatenated 479 with the entire Packet, including the packet header, all Packet TLVs 480 (other than Packet ICV TLVs) and all included Messages and their 481 message headers, in accordance with Section 8.1. 483 12.2.2. Message ICV TLV 485 When determining the for a message, the ICV is calculated 486 over the fields , , and - if present - (in that order), concatenated 488 with the entire message. The considerations in Section 9.1 MUST be 489 applied. 491 12.2.3. Address Block ICV TLV 493 When determining the for an address, the ICV is 494 calculated over the fields , 495 , and - if present - (in that order), 496 concatenated with the address, concatenated with any other values, 497 for example, any other address block TLV that is associated 498 with that address. A MANET routing protocol or MANET routing 499 protocol extension using Address Block ICV TLVs MUST specify how to 500 include any such concatenated attribute of the address in the 501 verification process of the ICV. The considerations in Section 10.2 502 MUST be applied. 504 12.3. Example of a Message including an ICV 506 The sample message depicted in Figure 1 is derived from appendix D of 507 [RFC5444]. The message contains an ICV Message TLV, with the value 508 representing a 16 octet long ICV of the whole message, and a 4 octet 509 long key identifier. The type extension of the Message TLV is 1, for 510 the specific decomposition of an ICV into a cryptographic function 511 over a hash value, as specified in Section 12. 513 0 1 2 3 514 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | PV=0 | PF=8 | Packet Sequence Number | Message Type | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | MF=15 | MAL=3 | Message Length = 44 | Msg. Orig Addr| 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Message Originator Address (cont) | Hop Limit | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Hop Count | Message Sequence Number | Msg. TLV Block| 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Length = 27 | ICV | MTLVF = 144 | MTLVExt = 1 | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 |Value Len = 23 | Hash Func | Crypto Func |Key ID length=4| 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Key Identifier | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | ICV Value | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | ICV Value (cont) | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | ICV Value (cont) | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | ICV Value (cont) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 1: Example message with ICV 541 13. IANA Considerations 543 This specification defines: 545 o Two Packet TLV types, which must be allocated from the 0-223 range 546 of the "Assigned Packet TLV Types" repository of [RFC5444] as 547 specified in Table 1, 549 o Two Message TLV types, which must be allocated from the 0-127 550 range of the "Assigned Message TLV Types" repository of [RFC5444] 551 as specified in Table 2, 553 o Two Address Block TLV types, which must be allocated from the 554 0-127 range of the "Assigned Address Block TLV Types" repository 555 of [RFC5444] as specified in Table 3. 557 This specification requests: 559 o Creation of type extension registries for these TLV types with 560 initial values as in Table 1 to Table 3. 562 IANA is requested to assign the same numerical value to the Packet 563 TLV, Message TLV and Address Block TLV types with the same name. 565 The following terms are used with the meanings defined in [BCP26]: 566 "Namespace", "Registration", and "Designated Expert". 568 The following policy is used with the meanings defined in [BCP26]: 569 "Expert Review". 571 13.1. Expert Review: Evaluation Guidelines 573 For the registries for TLV type extensions where an Expert Review is 574 required, the designated expert SHOULD take the same general 575 recommendations into consideration as are specified by [RFC5444]. 577 For the Timestamp TLV, the same type extensions for all Packet, 578 Message and Address Block TLVs SHOULD be numbered identically. 580 13.2. Packet TLV Type Registrations 582 IANA is requested to make allocations from the "Packet TLV Types" 583 namespace of [RFC5444] for the Packet TLVs specified in Table 1. 585 +-----------+------+-----------+------------------------------------+ 586 | Name | Type | Type | Description | 587 | | | Extension | | 588 +-----------+------+-----------+------------------------------------+ 589 | ICV | TBD1 | 0 | ICV of a packet | 590 | | | 1 | ICV, decomposed into cryptographic | 591 | | | | function over a hash value, as | 592 | | | | specified in Section 12 in this | 593 | | | | document. | 594 | | | 2-251 | Expert Review | 595 | | | 252-255 | Experimental Use | 596 | TIMESTAMP | TBD2 | 0 | Unsigned timestamp of arbitrary | 597 | | | | length, given by the TLV length | 598 | | | | field. The MANET routing protocol | 599 | | | | has to define how to interpret | 600 | | | | this timestamp | 601 | | | 1 | Unsigned 32-bit timestamp as | 602 | | | | specified in [POSIX] | 603 | | | 2 | NTP timestamp format as defined in | 604 | | | | [RFC4330] | 605 | | | 3 | Signed timestamp of arbitrary | 606 | | | | length with no constraints such as | 607 | | | | monotonicity. In particular, it | 608 | | | | may represent any random value | 609 | | | 4-251 | Expert Review | 610 | | | 252-255 | Experimental Use | 611 +-----------+------+-----------+------------------------------------+ 613 Table 1: Packet TLV types 615 13.3. Message TLV Type Registrations 617 IANA is requested to make allocations from the "Message TLV Types" 618 namespace of [RFC5444] for the Message TLVs specified in Table 2. 620 +-----------+------+-----------+------------------------------------+ 621 | Name | Type | Type | Description | 622 | | | Extension | | 623 +-----------+------+-----------+------------------------------------+ 624 | ICV | TBD3 | 0 | ICV of a message | 625 | | | 1 | ICV, decomposed into cryptographic | 626 | | | | function over a hash value, as | 627 | | | | specified in Section 12 in this | 628 | | | | document. | 629 | | | 2-251 | Expert Review | 630 | | | 252-255 | Experimental Use | 631 | TIMESTAMP | TBD4 | 0 | Unsigned timestamp of arbitrary | 632 | | | | length, given by the TLV length | 633 | | | | field. | 634 | | | 1 | Unsigned 32-bit timestamp as | 635 | | | | specified in [POSIX] | 636 | | | 2 | NTP timestamp format as defined in | 637 | | | | [RFC4330] | 638 | | | 3 | Signed timestamp of arbitrary | 639 | | | | length with no constraints such as | 640 | | | | monotonicity. In particular, it | 641 | | | | may represent any random value | 642 | | | 4-251 | Expert Review | 643 | | | 252-255 | Experimental Use | 644 +-----------+------+-----------+------------------------------------+ 646 Table 2: Message TLV types 648 13.4. Address Block TLV Type Registrations 650 IANA is requested to make allocations from the "Address Block TLV 651 Types" namespace of [RFC5444] for the Packet TLVs specified in 652 Table 3. 654 +-----------+------+-----------+------------------------------------+ 655 | Name | Type | Type | Description | 656 | | | Extension | | 657 +-----------+------+-----------+------------------------------------+ 658 | ICV | TBD5 | 0 | ICV of an object (e.g. an address) | 659 | | | 1 | ICV, decomposed into cryptographic | 660 | | | | function over a hash value, as | 661 | | | | specified in Section 12 in this | 662 | | | | document. | 663 | | | 2-251 | Expert Review | 664 | | | 252-255 | Experimental Use | 665 | TIMESTAMP | TBD6 | 0 | Unsigned timestamp of arbitrary | 666 | | | | length, given by the TLV length | 667 | | | | field. | 668 | | | 1 | Unsigned 32-bit timestamp as | 669 | | | | specified in [POSIX] | 670 | | | 2 | NTP timestamp format as defined in | 671 | | | | [RFC4330] | 672 | | | 3 | Signed timestamp of arbitrary | 673 | | | | length with no constraints such as | 674 | | | | monotonicity. In particular, it | 675 | | | | may represent any random value | 676 | | | 4-251 | Expert Review | 677 | | | 252-255 | Experimental Use | 678 +-----------+------+-----------+------------------------------------+ 680 Table 3: Address Block TLV types 682 13.5. Hash Function 684 IANA is requested to create a new registry for hash functions that 685 can be used when creating an ICV, as specified in Section 12 of this 686 document. The initial assignments and allocation policies are 687 specified in Table 4. 689 +-------------+-----------+-----------------------------------------+ 690 | Hash | Algorithm | Description | 691 | function | | | 692 | value | | | 693 +-------------+-----------+-----------------------------------------+ 694 | 0 | none | The "identity function": the hash value | 695 | | | of an object is the object itself | 696 | 1 | SHA1 | [SHS] | 697 | 2 | SHA224 | [SHS] | 698 | 3 | SHA256 | [SHS] | 699 | 4 | SHA384 | [SHS] | 700 | 5 | SHA512 | [SHS] | 701 | 6-251 | | Expert Review | 702 | 252-255 | | Experimental Use | 703 +-------------+-----------+-----------------------------------------+ 705 Table 4: Hash-Function registry 707 13.6. Cryptographic Algorithm 709 IANA is requested to create a new registry for the cryptographic 710 function, as specified in Section 12 of this document. Initial 711 assignments and allocation policies are specified in Table 5. 713 +----------------+-----------+--------------------------------------+ 714 | Cryptographic | Algorithm | Description | 715 | function value | | | 716 +----------------+-----------+--------------------------------------+ 717 | 0 | none | The "identity function": the value | 718 | | | of an encrypted hash is the hash | 719 | | | itself | 720 | 1 | RSA | [RFC3447] | 721 | 2 | DSA | [DSA] | 722 | 3 | HMAC | [RFC2104] | 723 | 4 | 3DES | [3DES] | 724 | 5 | AES | [AES] | 725 | 6 | ECDSA | [ECDSA] | 726 | 7-251 | | Expert Review | 727 | 252-255 | | Experimental Use | 728 +----------------+-----------+--------------------------------------+ 729 Table 5: Cryptographic function registry 731 14. Security Considerations 733 This document does not specify a protocol. It provides a syntactical 734 component for cryptographic ICVs of messages and packets as defined 735 in [RFC5444]. It can be used to address security issues of a MANET 736 routing protocol or MANET routing protocol extension. As such, it 737 has the same security considerations as [RFC5444]. 739 In addition, a MANET routing protocol or MANET routing protocol 740 extension that uses this specification MUST specify the usage as well 741 as the security that is attained by the cryptographic ICVs of a 742 message or a packet. 744 As an example, a MANET routing protocol that uses this component to 745 reject "badly formed" or "insecure" messages if a control message 746 does not contain a valid ICV, SHOULD indicate the security assumption 747 that if the ICV is valid, the message is considered valid. It also 748 SHOULD indicate the security issues that are counteracted by this 749 measure (e.g. link or identity spoofing) as well as the issues that 750 are not counteracted (e.g. compromised keys). 752 15. Acknowledgements 754 The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE), 755 Justin Dean (NRL), Christopher Dearlove (BAE), Paul Lambert 756 (Marvell), Jerome Milan (Ecole Polytechnique) and Henning Rogge 757 (FGAN) for their constructive comments on the document. 759 The authors also appreciate the detailed reviews from the Area 760 Directors, in particular Stewart Bryant (Cisco), Stephen Farrel 761 (Trinity College Dublin), and Robert Sparks (Tekelec), as well as 762 Donald Eastlake (Huawei) from the Security Directorate. 764 16. References 766 16.1. Normative References 768 [3DES] National Institute of Standards and Technology, 769 "Recommendation for the Triple Data Encryption Algorithm 770 (TDEA) Block Cipher", NIST Special Publication 800-67, 771 May 2004. 773 [AES] National Institute of Standards & Technology, 774 "Specification for the Advanced Encryption Standard 775 (AES)", FIPS 197, November 2001. 777 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 778 IANA Considerations Section in RFCs", RFC 5226, BCP 26, 779 May 2008. 781 [DSA] National Institute of Standards & Technology, "Digital ICV 782 Standard", NIST, FIPS PUB 186, May 1994. 784 [ECDSA] American National Standards Institute, "Public Key 785 Cryptography for the Financial Services Industry: The 786 Elliptic Curve Digital ICV Algorithm (ECDSA)", ANS X9.62- 787 2005, November 2005. 789 [POSIX] IEEE Computer Society, "1003.1-2008 Standard for 790 Information Technology - Portable Operating System 791 Interface (POSIX)", Base Specifications Issue 7, 792 December 2008. 794 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 795 Hashing for Message Authentication", RFC 2104, 796 February 1997. 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", RFC 2119, BCP 14, March 1997. 801 [RFC3447] Staddon, J. and B. Kaliski, "Public-Key Cryptography 802 Standards (PKCS) #1: RSA Cryptography Specifications 803 Version 2.1", RFC 3447, February 2003. 805 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 806 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 808 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 809 "Generalized MANET Packet/Message Format", RFC 5444, 810 February 2009. 812 [SHS] National Institute of Standards and Technology, "Secure 813 Hash Standard", NIST FIPS 180-2, August 2002. 815 16.2. Informative References 817 [OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized 818 Link State Routing Protocol version 2", work in 819 progress draft-ietf-manet-olsrv2-13.txt, October 2011. 821 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET 822 Neighborhood Discovery Protocol (NHDP)", RFC 6130, 823 March 2011. 825 Authors' Addresses 827 Ulrich Herberg 828 Fujitsu Laboratories of America 829 1240 E. Arques Ave. 830 Sunnyvale, CA, 94085 831 USA 833 Email: ulrich@herberg.name 834 URI: http://www.herberg.name/ 836 Thomas Heide Clausen 837 LIX, Ecole Polytechnique 838 91128 Palaiseau Cedex, 839 France 841 Phone: +33 6 6058 9349 842 Email: T.Clausen@computer.org 843 URI: http://www.thomasclausen.org/