idnits 2.17.1 draft-ietf-manet-rfc6622-bis-06.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 == Line 194 has weird spacing: '...-length is th...' -- The document date (November 15, 2013) is 3809 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-FIPS-186-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-FIPS-197' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP-800-107' ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Downref: Normative reference to an Informational RFC: RFC 4493 ** Downref: Normative reference to an Informational RFC: RFC 6090 -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-SP-800-67' -- Possible downref: Non-RFC (?) normative reference: ref. 'NIST-FIPS-180-4' -- Obsolete informational reference (is this intentional?): RFC 6622 (Obsoleted by RFC 7182) Summary: 5 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 Obsoletes: 6622 (if approved) T. Clausen 5 Intended status: Standards Track LIX, Ecole Polytechnique 6 Expires: May 19, 2014 C. Dearlove 7 BAE Systems ATC 8 November 15, 2013 10 Integrity Check Value and Timestamp TLV Definitions 11 for Mobile Ad Hoc Networks (MANETs) 12 draft-ietf-manet-rfc6622-bis-06 14 Abstract 16 This document revises, extends and replaces RFC 6622. It describes 17 general and flexible TLVs for representing cryptographic Integrity 18 Check Values (ICVs) and timestamps, using the generalized Mobile Ad 19 Hoc Network (MANET) packet/message format defined in RFC 5444. It 20 defines two Packet TLVs, two Message TLVs, and two Address Block TLVs 21 for affixing ICVs and timestamps to a packet, a message, and one or 22 more addresses, respectively. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 19, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1. Differences from RFC6622 . . . . . . . . . . . . . . . . 4 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 62 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 6 63 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 7 64 6. General ICV TLV Structure . . . . . . . . . . . . . . . . . . 8 65 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 9 66 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . . . 9 68 8.2. TIMESTAMP Packet TLV . . . . . . . . . . . . . . . . . . 10 69 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 9.1. ICV Message TLV . . . . . . . . . . . . . . . . . . . . . 11 71 9.2. TIMESTAMP Message TLV . . . . . . . . . . . . . . . . . . 11 72 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 11 73 10.1. ICV Address Block TLV . . . . . . . . . . . . . . . . . . 11 74 10.2. TIMESTAMP Address Block TLV . . . . . . . . . . . . . . . 12 75 11. ICV: Basic . . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 12. ICV: Hash Function and Cryptographic Function . . . . . . . . 13 77 12.1. General ICV TLV Structure . . . . . . . . . . . . . . . . 13 78 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 15 79 12.1.2. Parameters . . . . . . . . . . . . . . . . . . . . . 15 80 12.2. Considerations for Calculating the ICV . . . . . . . . . 16 81 12.2.1. ICV Packet TLV . . . . . . . . . . . . . . . . . . . 16 82 12.2.2. ICV Message TLV . . . . . . . . . . . . . . . . . . . 17 83 12.2.3. ICV Address Block TLV . . . . . . . . . . . . . . . . 17 84 12.3. Example of a Message Including an ICV . . . . . . . . . . 18 85 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 86 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . 19 87 13.2. Packet TLV Types . . . . . . . . . . . . . . . . . . . . 19 88 13.3. Message TLV Types . . . . . . . . . . . . . . . . . . . . 20 89 13.4. Address Block TLV Types . . . . . . . . . . . . . . . . . 20 90 13.5. ICV Packet TLV Type Extensions . . . . . . . . . . . . . 20 91 13.6. TIMESTAMP Packet TLV Type Extensions . . . . . . . . . . 21 92 13.7. ICV Message TLV Type Extensions . . . . . . . . . . . . . 22 93 13.8. TIMESTAMP Message TLV Type Extensions . . . . . . . . . . 23 94 13.9. ICV Address Block TLV Type Extensions . . . . . . . . . . 23 95 13.10. TIMESTAMP Address Block TLV Type Extensions . . . . . . . 24 96 13.11. Hash Functions . . . . . . . . . . . . . . . . . . . . . 25 97 13.12. Cryptographic Functions . . . . . . . . . . . . . . . . . 26 98 14. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 100 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 16.1. Normative References . . . . . . . . . . . . . . . . . . 27 102 16.2. Informative References . . . . . . . . . . . . . . . . . 29 104 1. Introduction 106 [RFC Editor note: Please replace "xxxx" throughout this document with 107 the RFC number assigned to this document, and remove this note.] 109 This document specifies a syntactical representation of security- 110 related information for use with [RFC5444] addresses, messages, and 111 packets, and also specifies IANA registrations of TLV types and type 112 extension registries for these TLV types. This specification does 113 not represent a stand-alone protocol, but is intended for use by 114 MANET routing protocols, or security extensions thereof. 116 Specifically, this document, which revises, extends, and replaces 117 [RFC6622], specifies: 119 o Two kinds of TLV: one for carrying Integrity Check Values (ICVs) 120 and one for timestamps in packets, messages, and address blocks as 121 defined by [RFC5444]. 123 o A generic framework for use of these TLVs, accounting for specific 124 features of Packet, Message and Address Block TLVs. 126 o IANA registrations for TLVs, and registries for TLV Type 127 Extensions, replacing those from [RFC6622]. 129 This document specifies IANA registries for recording code points for 130 ICV TLVs and TIMESTAMP TLVs, as well as timestamps, hash-functions, 131 and cryptographic functions. 133 Moreover, in Section 12, this document defines the following: 135 o A method for generating ICVs using a combination of a 136 cryptographic function and a hash function, and for including such 137 ICVs in the value field of a TLV. 139 1.1. Differences from RFC6622 141 This document obsoletes [RFC6622], replacing that document as the 142 specification of two TLV types, TIMESTAMP and ICV, for packets, 143 messages and address blocks. For the ICV type, this document 144 specifies a new type extension, 2 (see Section 12), in addition to 145 including the original type extensions (0 and 1) from [RFC6622]. 147 The TLV value of an ICV TLV with type extension 2 has the same 148 internal structure as an ICV TLV with type extension 1, but is 149 calculated also over the source address of the IP datagram carrying 150 the packet, message, or Address Block. The rationale for adding this 151 type extension is that some MANET protocols, such as [RFC6130], use 152 the IP source address of the IP datagram carrying the packet, message 153 or Address Block, e.g., to identify links with neighbor routers. If 154 this address is not otherwise contained in the packet, message, or 155 Address Block payload (which is permitted, e.g., in [RFC6130]), then 156 the address is not protected against tampering. 158 This document also incorporates a number of editorial improvements 159 over [RFC6622]. In particular, it makes it clear that an ICV TLV may 160 be used to carry a truncated ICV, and that a single- or multi-value 161 TIMESTAMP or ICV Address Block TLV may cover more than one address. 162 Moreover, to be consistent with the terminology in [RFC5444], the 163 name of the TLVs specified in this document have changed from "Packet 164 ICV TLV" to "ICV Packet TLV" and from "Packet TIMESTAMP TLV" to 165 "TIMESTAMP Packet TLV" (and similar for Message and Address Block 166 TLVs). 168 A normative requirement in Section 9.2 has changed from SHOULD to 169 MUST in the following sentence: "If a message contains one or more 170 TIMESTAMP TLVs and one or more ICV TLVs, then the TIMESTAMP TLVs (as 171 well as any other Message TLVs) MUST be added to the message before 172 the ICV TLVs (...)". 174 2. Terminology 176 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 177 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 178 "OPTIONAL" in this document are to be interpreted as described in 179 [RFC2119]. 181 This document uses the terminology and notation defined in [RFC5444]. 182 In particular, the following TLV fields and notation from [RFC5444] 183 are used in this specification: 185 is the hop limit of a message, as specified in 186 Section 5.2 of [RFC5444]. 188 is the hop count of a message, as specified in 189 Section 5.2 of [RFC5444]. 191 is the length of the value field in a TLV in octets, as 192 specified in Section 5.4.1 of [RFC5444]. 194 single-length is the length of a single value in the value field in 195 a TLV in octets, as specified in Section 5.4.1 of [RFC5444]. (It 196 is equal to except in a multivalue Address Block TLV.) 198 In addition to the regular expressions defined in Section 2.1.1 of 199 [RFC5444] this document defines: 201 + - One or more occurrences of the preceding element or group. 203 3. Applicability Statement 205 MANET routing protocols using the format defined in [RFC5444] are 206 accorded the ability to carry additional information in control 207 messages and packets, through the inclusion of TLVs. Information so 208 included MAY be used by a MANET routing protocol, or by an extension 209 of a MANET routing protocol, according to its specification. 211 This document specifies how to include an ICV for a packet, a 212 message, and addresses in Address Blocks within a message, using such 213 TLVs. This document also specifies how to treat an empty Packet TLV 214 Block, and "mutable" fields, specifically the and 215 fields, if present in the Message Header when 216 calculating ICVs, such that the resulting ICV can be correctly 217 verified by any recipient. 219 This document describes a generic framework for creating ICVs, and 220 how to include these ICVs in TLVs. In Section 12, an example method 221 for calculating such ICVs is given, using a cryptographic function 222 and a hash function, for which two TLV type extensions are allocated. 224 This document does not specify a protocol. Protocol specifications 225 that make use of the framework, specified in this document, will 226 reference this document in a normative way, and may require the 227 implementation of some or all of the algorithms described in this 228 document. As this document does not specify a protocol itself, key 229 management and key exchange mechanisms are out of scope, and may be 230 specified in the protocol or protocol extension using this 231 specification. 233 4. Security Architecture 235 MANET routing protocol specifications may have a clause allowing a 236 control message to be rejected as "badly formed" or "insecure" prior 237 to the message being processed or forwarded. In particular, MANET 238 routing protocols such as the Neighborhood Discovery Protocol (NHDP) 239 [RFC6130] and the Optimized Link State Routing Protocol version 2 240 [OLSRv2] recognize external reasons (such as failure to verify an 241 ICV) for rejecting a message that would be considered "invalid for 242 processing". 244 This architecture is a result of the observation that with respect to 245 security in MANETs, "one size rarely fits all" and that MANET routing 246 protocol deployment domains have varying security requirements 247 ranging from "unbreakable" to "virtually none". The virtue of this 248 approach is that MANET routing protocol specifications (and 249 implementations) can remain "generic", with extensions providing 250 proper security mechanisms specific to a deployment domain. 252 The MANET routing protocol "security architecture", in which this 253 specification situates itself, can therefore be summarized as 254 follows: 256 o MANET routing protocol specifications, each with a clause allowing 257 an extension to reject a message (prior to processing/forwarding) 258 as "badly formed" or "insecure". 260 o MANET routing protocol security extensions, each rejecting 261 messages as "badly formed" or "insecure", as appropriate for a 262 given security requirement specific to a deployment domain. 264 o Code points and an exchange format for information, necessary for 265 specification of such MANET routing protocol security extensions. 267 This document addresses the last of the points above, by specifying a 268 common exchange format for cryptographic ICVs and timestamps, making 269 reservations from within the Packet TLV, Message TLV, and Address 270 Block TLV registries of [RFC5444], to be used by (and shared among) 271 MANET routing protocol security extensions. 273 For the specific decomposition of an ICV using a cryptographic 274 function and a hash function (specified in Section 12), this document 275 specifies two IANA registries (see Section 13) for code points for 276 hash functions and cryptographic functions. 278 With respect to [RFC5444], this document is: 280 o Intended to be used in the non-normative, but intended, mode of 281 use described in Appendix B of [RFC5444]. 283 o A specific example of the Security Considerations section of 284 [RFC5444] (the authentication part). 286 5. Overview and Functioning 288 This document specifies a syntactical representation of security- 289 related information for use with [RFC5444] addresses, messages, and 290 packets, and also specifies IANA registrations (see Section 13) of 291 TLV types and type extension registries for these TLV types. 293 Moreover, this document provides guidelines for how MANET routing 294 protocols, and MANET routing protocol extensions using this 295 specification, should treat ICV and Timestamp TLVs, and mutable 296 fields in messages. This specification does not represent a stand- 297 alone protocol. MANET routing protocols, and MANET routing protocol 298 extensions using this specification, MUST provide instructions as to 299 how to handle packets, messages, and addresses with security 300 information, associated as specified in this document. 302 This document specifies TLV type assignments (see Section 13) from 303 the registries defined for Packet, Message, and Address Block TLVs in 304 [RFC5444]. When a TLV type is assigned from one of these registries, 305 a registry for type extensions for that TLV type is created by IANA. 306 This document specifies these type extension registries, in order to 307 specify internal structure (and accompanying processing) of the 308 field of a TLV. 310 For example, and as reported in this document, an ICV TLV with type 311 extension = 0 specifies that the field has no pre-defined 312 internal structure, but is simply a sequence of octets. An ICV TLV 313 with type extension = 1 specifies that the field has a pre- 314 defined internal structure and defines its interpretation. An ICV 315 TLV with type extension = 2 (added in this document) is the same as 316 an ICV TLV with type extension = 1, except that the integrity 317 protection also covers the source address of the IP datagram carrying 318 the packet, message, or Address Block. 320 Specifically, with type extension = 1 or type extension = 2, the 321 field contains the result of combining a cryptographic 322 function and a hash function, calculated over the contents of the 323 packet, message, or Address Block. The field contains sub- 324 fields indicating which hash function and cryptographic function have 325 been used, as specified in Section 12. 327 Other documents can request assignments for other type extensions; if 328 they do so, they MUST specify their internal structure (if any) and 329 interpretation. 331 6. General ICV TLV Structure 333 The value of the ICV TLV is: 335 := + 337 where: 339 is a field, of length octets (except in a 340 multivalue Address Block TLV, where each is of length 341 single-length octets) that contains the information to be 342 interpreted by the ICV verification process, as specified by the 343 type extension. 345 Note that this does not specify how to calculate the nor 346 the internal structure thereof, if any; such information MUST be 347 specified by the type extension for the ICV TLV type; see Section 13. 348 This document specifies three such type extensions -- one for ICVs 349 without pre-defined structures, and two for ICVs constructed 350 combining a cryptographic function and a hash function. 352 7. General Timestamp TLV Structure 354 The value of the Timestamp TLV is: 356 := + 358 where: 360 is a field, of length octets (except in a 361 multivalue Address Block TLV, where each is of length 362 single-length octets) that contains the timestamp. 364 Note that this does not specify how to calculate the nor 365 the internal structure thereof, if any; such information MUST be 366 specified by the type extension for the TIMESTAMP TLV type; see 367 Section 13. 369 A timestamp is essentially "freshness information". As such, its 370 setting and interpretation are to be determined by the MANET routing 371 protocol, or MANET routing protocol extension, that uses the 372 timestamp and can, for example, correspond to a POSIX timestamp, GPS 373 timestamp, or a simple sequence number. Note that ensuring time 374 synchronization in a MANET may be difficult because of the 375 decentralized architecture as well as highly dynamic topology due to 376 mobility or other factors. It is out of scope for this document to 377 specify a time synchronization mechanism. 379 8. Packet TLVs 381 Two Packet TLVs are defined: one for including the cryptographic ICV 382 of a packet and one for including the timestamp indicating the time 383 at which the cryptographic ICV was calculated. 385 8.1. ICV Packet TLV 387 An ICV Packet TLV is an example of an ICV TLV as described in 388 Section 6. When determining the for a packet, and adding 389 an ICV Packet TLV to a packet, the following considerations MUST be 390 applied: 392 o Because packets as defined in [RFC5444] are never forwarded by 393 routers, no special considerations are required regarding mutable 394 fields (i.e., and ), if present 395 within any messages in the packet, when calculating the ICV. 397 o Any ICV Packet TLVs already present in the Packet TLV Block MUST 398 be removed before calculating the ICV, and the Packet TLV Block 399 size MUST be recalculated accordingly. 401 o If the Packet TLV Block now contains no Packet TLVs, the Packet 402 TLV Block MUST be removed, and the phastlv bit in the 403 field in the Packet Header MUST be cleared ('0'). 405 o Any removed ICV Packet TLVs MUST be restored after having 406 calculated the ICV, and the Packet TLV Block size MUST be 407 recalculated accordingly. 409 o When any removed ICV Packet TLVs, and the newly calculated ICV 410 Packet TLV, are added to the packet, if there is no Packet TLV 411 Block then one MUST be added, including setting ('1') the phastlv 412 bit in the field in the Packet Header. 414 The rationale for removing any ICV Packet TLVs already present prior 415 to calculating the ICV is that several ICV TLVs may be added to the 416 same packet, e.g., using different ICV cryptographic and/or hash 417 functions. The rationale for removing an empty Packet TLV Block is 418 because the receiver of the packet cannot tell the difference between 419 what was an absent Packet TLV Block, and what was an empty Packet TLV 420 Block when removing and verifying the ICV Packet TLV if no other 421 Packet TLVs are present. 423 8.2. TIMESTAMP Packet TLV 425 A TIMESTAMP Packet TLV is an example of a Timestamp TLV as described 426 in Section 7. If a packet contains one or more TIMESTAMP TLVs and 427 one or more ICV TLVs, then the TIMESTAMP TLVs (as well as any other 428 Packet TLVs) MUST be added to the packet before the ICV TLVs, in 429 order to include the timestamps and other TLVs in the calculation of 430 the ICVs. 432 9. Message TLVs 434 Two Message TLVs are defined: one for including the cryptographic ICV 435 of a message and one for including the timestamp indicating the time 436 at which the cryptographic ICV was calculated. 438 9.1. ICV Message TLV 440 An ICV Message TLV is an example of an ICV TLV as described in 441 Section 6. When determining the for a message, the 442 following considerations MUST be applied: 444 o The fields and , if present in the 445 Message Header, MUST both be assumed to have the value 0 (zero) 446 when calculating the ICV. 448 o Any ICV Message TLVs already present in the Message TLV Block MUST 449 be removed before calculating the ICV, and the message size as 450 well as the Message TLV Block size MUST be recalculated 451 accordingly. Also, all relevant TLVs other than ICV TLVs MUST be 452 added prior to TCV value calculation. 454 o Any removed ICV Message TLVs MUST be restored after having 455 calculated the ICV, and the message size as well as the Message 456 TLV Block size MUST be recalculated accordingly. 458 The rationale for removing any ICV Message TLVs already present prior 459 to calculating the ICV is that several ICV TLVs may be added to the 460 same message, e.g., using different ICV cryptographic and/or hash 461 functions. 463 9.2. TIMESTAMP Message TLV 465 A TIMESTAMP Message TLV is an example of a Timestamp TLV as described 466 in Section 7. If a message contains one or more TIMESTAMP TLVs and 467 one or more ICV TLVs, then the TIMESTAMP TLVs (as well as any other 468 Message TLVs) MUST be added to the message before the ICV TLVs, in 469 order to include the timestamps and other Message TLVs in the 470 calculation of the ICV. 472 10. Address Block TLVs 474 Two Address Block TLVs are defined: one for associating a 475 cryptographic ICV to one or more addresses and their associated 476 information, and one for including the timestamp indicating the time 477 at which the cryptographic ICV was calculated. 479 10.1. ICV Address Block TLV 481 An ICV Address Block TLV is an example of an ICV TLV as described in 482 Section 6. The ICV is calculated over one or more addresses, 483 concatenated with any other values -- for example, other Address 484 Block TLV fields -- associated with those addresses. A MANET 485 routing protocol, or MANET routing protocol extension, using ICV 486 Address Block TLVs MUST specify how to include any such concatenated 487 attributes of the addresses in the calculation and verification 488 processes for the ICV. When determining an for one or 489 more addresses, the following consideration MUST be applied: 491 o If other TLV values are concatenated with the addresses for 492 calculating the ICV, the corresponding TLVs MUST NOT be ICV 493 Address Block TLVs already associated with any of the addresses. 495 The rationale for not concatenating the addresses with any ICV TLV 496 values already associated with the addresses when calculating the ICV 497 is that several ICVs may be added to the same address or addresses, 498 e.g., using different ICV cryptographic and/or hash functions, and 499 the order of addition is not known to the recipient. 501 10.2. TIMESTAMP Address Block TLV 503 A TIMESTAMP Address Block TLV is an example of a Timestamp TLV as 504 described in Section 7. If one or more TIMESTAMP TLVs and one or 505 more ICV TLVs are associated with an address, the relevant TIMESTAMP 506 TLV (s) MUST be included before calculating the value of 507 the ICV to be contained in the ICV TLV value (i.e., concatenated with 508 the associated addresses and any other values as described in 509 Section 10.1). 511 11. ICV: Basic 513 The basic ICV, represented by way of an ICV TLV with type extension = 514 0, has as TLV value a simple bit-field without specified structure 515 (i.e, without explicitly included hash function, crypto function, key 516 ID or other parameters). Moreover, it is not specified how to 517 calculate the . It is assumed that the mechanism 518 specifying how ICVs are calculated and verified, as well as which 519 parameters (if any) need to be exchanged prior to using the TLV with 520 type extension 0, is established outside of this specification, e.g., 521 by administrative configuration or external out-of-band signaling. 523 The , when using type extension = 0, is: 525 := 527 where: 529 is a field, of length octets (or single-length 530 octets in a multivalue Address Block TLV) that contains the 531 cryptographic ICV. 533 12. ICV: Hash Function and Cryptographic Function 535 One common way of calculating an ICV is combining a cryptographic 536 function and a hash function applied to the content. This 537 decomposition is specified in this section, using either type 538 extension = 1 or type extension = 2, in the ICV TLVs. 540 12.1. General ICV TLV Structure 542 The following data structure allows representation of a cryptographic 543 ICV, including specification of the appropriate hash function and 544 cryptographic function used for calculating the ICV: 546 := 547 548 549 ? 550 552 where: 554 is a one octet unsigned integer field specifying the 555 hash function. 557 is a one octet unsigned integer field 558 specifying the cryptographic function. 560 is a one octet unsigned integer field specifying the 561 length of the field as a number of octets. The value 562 zero (0x00) is reserved for using a single pre-installed, shared 563 key. 565 is a field specifying the key identifier of the key that 566 was used to calculate the ICV of the message, which allows unique 567 identification of different keys with the same originator. It is 568 the responsibility of each key originator to make sure that 569 actively used keys that it issues have distinct key identifiers. 570 If equals zero (0x00), the field is not 571 contained in the TLV, and a single pre-installed, shared key is 572 used. 574 is a field with length - 3 - 575 octets (except in a multivalue Address Block TLV, in which it is 576 single-length - 3 - octets) and which contains the 577 cryptographic ICV. 579 The version of this TLV, specified in this section, assumes that, 580 unless otherwise specified, calculating the ICV can be decomposed 581 into: 583 ICV-value = cryptographic-function(hash-function(content)) 585 In some cases a different combination of cryptographic function and 586 hash function may be specified. This is the case for the HMAC 587 function, which is specified as defined in Section 13.12, using the 588 hash function twice. Using cryptographic-function "none" is provided 589 for symmetry and possible future use, but it SHOULD NOT be used with 590 any currently specified hash-function. 592 The difference between the two type extensions is that in addition to 593 the information covered by the ICV using type extension 1 (which is 594 detailed in the following sections), the ICV using type extension 2 595 also MUST cover the source address of the IP datagram carrying the 596 corresponding packet, message, or Address Block. 598 The field MAY be truncated after being calculated, this is 599 indicated by its length, calculated as described above. The 600 truncation MUST be as specified for the relevant cryptographic 601 function (and, if appropriate, hash function). 603 o When using truncation, the guidelines for minimal ICV length set 604 out in [NIST-SP-800-107] MUST be followed. In particular the 605 field when using HMAC MUST NOT be truncated below 4 606 octets. 608 o The truncated ICV length MUST be so large that the probability of 609 success of a dictionary attack is acceptably small. Such a 610 success will arise if the ICV of a spoofed packet or message is 611 verified. The probability of success is a function of (a) how 612 many routers can be attacked, (b) how fast a router can receive 613 packets or messages and attempt to verify their ICV, (c) the 614 truncated ICV length, and (d) the lifetime of the network. If the 615 truncated ICV length in bits is L, then 2^L packets or messages 616 are required to attack with certainty of success. With a 617 verification rate of R packets/messages per second, applied to N 618 routers over an available time of T, the probability of success is 619 given by NRT/2^L. If this is to not exceed a probability of P, 620 then L > log2(NRT/P). For example if N is 32, R is 1000, T is 621 86400 (I day) and P is 10^-6, then L must be at least 52 bits. 623 Some of the cryptographic and hash functions listed in Section 13 624 require the length of the content to be digitally signed to be a 625 multiple of a certain number of octets. As a consequence, they 626 specify padding mechanisms, e.g., AES-CMAC [RFC4493] specifies a 627 padding mechanism for message lengths that are not equal to a 628 multiple of 16 octets. Implementations of the framework in this 629 document MUST support appropriate padding mechanisms, as specified in 630 the cryptographic or hash function specifications. 632 The hash function and the cryptographic function correspond to the 633 entries in two IANA registries, which are described in Section 13. 635 12.1.1. Rationale 637 The rationale for separating the hash function and the cryptographic 638 function into two octets instead of having all combinations in a 639 single octet -- possibly as a TLV type extension -- is that adding 640 further hash functions or cryptographic functions in the future may 641 lead to a non-contiguous number space, as well as providing a smaller 642 overall space. 644 The rationale for not including a field that lists parameters of the 645 cryptographic ICV in the TLV is that, before being able to validate a 646 cryptographic ICV, routers have to exchange or acquire keys. Any 647 additional parameters can be provided together with the keys in that 648 bootstrap process. It is therefore not necessary, and would even 649 entail an extra overhead, to transmit the parameters within every 650 message. 652 The rationale for the addition of type extension 2 is that the source 653 code address is used in some cases, such as when processing HELLO 654 messages in [RFC6130]. This is applicable only to packets (which 655 only ever travel one hop) and messages (and their Address Blocks) 656 that only travel one hop. It is not applicable to messages that may 657 be forwarded more than one hop, such as TC messages in [OLSRv2]. 659 12.1.2. Parameters 661 As described in Section 12.1.1, parameters such as RSA signature 662 scheme, RSA common exponent etc. are selected administratively on 663 each router before using this framework in a MANET, in addition to 664 exchanging the keys between MANET routers. This was a design 665 decision in [RFC6622] and is kept in this specification for reasons 666 of backwards-compatibility. 668 The following parameters are RECOMMENDED and SHOULD be those chosen 669 administratively, unless there are good reasons otherwise: 671 o For crypto function RSA: 673 * Signature scheme: RSASSA-PSS with the default parameters: 674 rSASSA-PSS-Default-Identifier (as defined in [RFC3447]) 676 * Common exponent: 65537 678 o For crypto function ECDSA: 680 * Curve name: exchanged as part of key distribution 682 * Hash function: The hash function MUST be pinned to the curve, 683 i.e., use SHA-256 for the p-256 curve, SHA-384 for p-384 etc. 685 o For crypto function AES: 687 * Authentication algorithm: CMAC (as defined in [RFC4493] 689 * Hash function: None 691 12.2. Considerations for Calculating the ICV 693 The considerations listed in the following subsections MUST be 694 applied when calculating the ICV for Packet, Message, and Address 695 Block TLVs, respectively. 697 12.2.1. ICV Packet TLV 699 When determining the for a packet, with type extension = 700 1: 702 o The ICV is calculated over the fields , 703 , , and -- if present -- 704 (in that order), followed by the entire packet, including 705 the Packet Header, including all Packet TLVs (other than ICV 706 Packet TLVs), and all included messages. The considerations of 707 Section 8.1 MUST be applied. 709 When determining the for a packet, with type extension = 710 2: 712 o The same procedure as for type extension = 1 is used, except that 713 the data used consists of a representation of the source address 714 of the IP datagram carrying the packet, followed by the remaining 715 data (as for type extension = 1). The representation of the 716 source address consists of a single octet containing the address 717 length, in octets, followed by that many octets containing the 718 address in network byte order. 720 12.2.2. ICV Message TLV 722 When determining the for a message, with type extension = 723 1: 725 o The ICV is calculated over the fields , 726 , , and -- if present -- 727 (in that order), followed by the entire message. The 728 considerations in Section 9.1 MUST be applied. 730 When determining the for a message, with type extension = 731 2: 733 o The same procedure as for type extension = 1 is used, except that 734 the data used consists of a representation of the source address 735 of the IP datagram carrying the message, followed by the remaining 736 data (as for type extension = 1). The representation of the 737 source address consists of a single octet containing the address 738 length, in octets, followed by that many octets containing the 739 address in network byte order. 741 12.2.3. ICV Address Block TLV 743 When determining the for one or more addresses, with type 744 extension = 1: 746 o The ICV is calculated over the fields , 747 , , and -- if present -- 748 (in that order), followed by the addresses, and followed 749 by any other values -- for example, other address block TLV 750 s that are associated with those addresses. A MANET 751 routing protocol, or MANET routing protocol extension, using ICV 752 Address Block TLVs MUST specify how to include any such 753 concatenated attribute of the addresses in the verification 754 process of the ICV. The considerations in Section 10.1 MUST be 755 applied. 757 When determining the for one or more addresses, with type 758 extension = 2: 760 o The same procedure as for type extension = 1 is used, except that 761 the data used consists of a representation of the source address 762 of the IP datagram carrying the Address Block, followed by the 763 remaining data (as for type extension = 1). The representation of 764 the source address consists of a single octet containing the 765 address length, in octets, followed by that many octets containing 766 the address in network byte order. 768 12.3. Example of a Message Including an ICV 770 The sample message depicted in Figure 1 is derived from Appendix D of 771 [RFC5444]. The message contains an ICV Message TLV, with the value 772 representing an ICV that is 16 octets long of the whole message, and 773 a key identifier that is 4 octets long. The type extension of the 774 Message TLV is 1, for the specific decomposition of an ICV using a 775 cryptographic function and a hash function, as specified in 776 Section 12. 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | PV=0 | PF=8 | Packet Sequence Number | Message Type | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | MF=15 | MAL=3 | Message Length = 44 | Msg Orig Addr | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Message Originator Address (cont) | Hop Limit | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Hop Count | Message Sequence Number | Msg TLV Block | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Length = 27 | ICV | MTLVF = 144 | MTLVExt = 1 | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 |Value Len = 23 | Hash Func | Crypto Func |Key ID length=4| 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | Key Identifier | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | ICV Value | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | ICV Value (cont) | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | ICV Value (cont) | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | ICV Value (cont) | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 Figure 1: Example Message with ICV 806 13. IANA Considerations 808 The IANA registrations for TLV Types and the TLV Type Extension 809 registries given in this specification replace the identical 810 registrations and registries from [RFC6622]. 812 This specification defines the following TLV Types, replacing the 813 original specifications in [RFC6622]: 815 o Two Packet TLV Types, which have been allocated from the 0-223 816 range of the "Packet TLV Types" repository of [RFC5444], as 817 specified in Table 1. 819 o Two Message TLV Types, which have been allocated from the 0-127 820 range of the "Message TLV Types" repository of [RFC5444], as 821 specified in Table 2. 823 o Two Address Block TLV Types, which have been allocated from the 824 0-127 range of the "Address Block TLV Types" repository of 825 [RFC5444], as specified in Table 3. 827 This specification updates the following registries that were created 828 in [RFC6622]: 830 o A type extension registry for each of these TLV types with values 831 as listed in Tables 1, 2, and 3. 833 The following terms are used as defined in [BCP26]: "Namespace", 834 "Registration", and "Designated Expert". 836 The following policy is used as defined in [BCP26]: "Expert Review". 838 13.1. Expert Review: Evaluation Guidelines 840 For TLV type extensions registries where an Expert Review is 841 required, the Designated Expert SHOULD take the same general 842 recommendations into consideration as those specified by [RFC5444]. 844 For both TIMESTAMP and ICV TLVs, functionally similar extensions for 845 Packet, Message, and Address Block TLVs SHOULD be numbered 846 identically. 848 13.2. Packet TLV Types 850 IANA has, in accordance with [RFC6622], made allocations from the 851 "Packet TLV Types" namespace of [RFC5444] for the Packet TLVs 852 specified in Table 1. IANA is requested to modify this allocation as 853 indicated. 855 +------+-------------+-----------+ 856 | Type | Description | Reference | 857 +------+-------------+-----------+ 858 | 5 | ICV | RFC xxxx | 859 | 6 | TIMESTAMP | RFC xxxx | 860 +------+-------------+-----------+ 862 Table 1: Packet TLV Types 864 13.3. Message TLV Types 866 IANA has, in accordance with [RFC6622], made allocations from the 867 "Message TLV Types" namespace of [RFC5444] for the Message TLVs 868 specified in Table 2. IANA is requested to modify this allocation as 869 indicated. 871 +------+-------------+-----------+ 872 | Type | Description | Reference | 873 +------+-------------+-----------+ 874 | 5 | ICV | RFC xxxx | 875 | 6 | TIMESTAMP | RFC xxxx | 876 +------+-------------+-----------+ 878 Table 2: Message TLV Types 880 13.4. Address Block TLV Types 882 IANA has, in accordance with [RFC6622], made allocations from the 883 "Address Block TLV Types" namespace of [RFC5444] for the Packet TLVs 884 specified in Table 3. IANA is requested to modify this allocation as 885 indicated. 887 +------+-------------+-----------+ 888 | Type | Description | Reference | 889 +------+-------------+-----------+ 890 | 5 | ICV | RFC xxxx | 891 | 6 | TIMESTAMP | RFC xxxx | 892 +------+-------------+-----------+ 894 Table 3: Address Block TLV Types 896 13.5. ICV Packet TLV Type Extensions 898 IANA has, in accordance with [RFC6622], made allocations from the 899 "ICV Packet TLV Type Extensions" namespace of [RFC6622] for the 900 Packet TLVs specified in Table 4. IANA is requested to modify this 901 allocation (including defining type extension = 2) as indicated. 903 +-----------+-------------------------------------------+-----------+ 904 | Type | Description | Reference | 905 | Extension | | | 906 +-----------+-------------------------------------------+-----------+ 907 | 0 | ICV of a packet | RFC xxxx | 908 | 1 | ICV, using a cryptographic function and a | RFC xxxx | 909 | | hash function, as specified in Section 12 | | 910 | | of this document | | 911 | 2 | ICV, using a cryptographic function and a | RFC xxxx | 912 | | hash function, and including the IP | | 913 | | datagram source address, as specified in | | 914 | | Section 12 of this document | | 915 | 3-251 | Unassigned; Expert Review | | 916 | 252-255 | Experimental Use | RFC xxxx | 917 +-----------+-------------------------------------------+-----------+ 919 Table 4: ICV Packet TLV Type Extensions 921 More than one ICV Packet TLV with the same type extension MAY be 922 included in a packet if these represent different ICV calculations 923 (e.g., with type extension 1 or 2 and different cryptographic 924 function and/or hash function, or with a different key identifier). 925 ICV Packet TLVs that carry what is declared to be the same 926 information MUST NOT be included in the same packet. 928 13.6. TIMESTAMP Packet TLV Type Extensions 930 IANA has, in accordance with [RFC6622], made allocations from the 931 "TIMESTAMP Packet TLV Type Extensions" namespace of [RFC6622] for the 932 Packet TLVs specified in Table 5. IANA is requested to modify this 933 allocation as indicated. 935 +-----------+-------------------------------------------+-----------+ 936 | Type | Description | Reference | 937 | Extension | | | 938 +-----------+-------------------------------------------+-----------+ 939 | 0 | Unsigned timestamp of arbitrary length, | RFC xxxx | 940 | | given by the TLV Length field. The MANET | | 941 | | routing protocol has to define how to | | 942 | | interpret this timestamp | | 943 | 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx | 944 | | in [IEEE 1003.1-2008 (POSIX)] | | 945 | 2 | NTP timestamp format, as specified in | RFC xxxx | 946 | | [RFC5905] | | 947 | 3 | Signed timestamp of arbitrary length with | RFC xxxx | 948 | | no constraints such as monotonicity. In | | 949 | | particular, it may represent any random | | 950 | | value | | 951 | 4-251 | Unassigned; Expert Review | | 952 | 252-255 | Experimental Use | RFC xxxx | 953 +-----------+-------------------------------------------+-----------+ 955 Table 5: TIMESTAMP Packet TLV Type Extensions 957 More than one TIMESTAMP Packet TLV with the same type extension MUST 958 NOT be included in a packet. 960 13.7. ICV Message TLV Type Extensions 962 IANA has, in accordance with [RFC6622], made allocations from the 963 "ICV Message TLV Type Extensions" namespace of [RFC6622] for the 964 Message TLVs specified in Table 6. IANA is requested to modify this 965 allocation (including defining type extension = 2) as indicated. 967 +-----------+-------------------------------------------+-----------+ 968 | Type | Description | Reference | 969 | Extension | | | 970 +-----------+-------------------------------------------+-----------+ 971 | 0 | ICV of a message | RFC xxxx | 972 | 1 | ICV, using a cryptographic function and a | RFC xxxx | 973 | | hash function, as specified in Section 12 | | 974 | | of this document | | 975 | 2 | ICV, using a cryptographic function and a | RFC xxxx | 976 | | hash function, and including the IP | | 977 | | datagram source address, as specified in | | 978 | | Section 12 of this document | | 979 | 3-251 | Unassigned; Expert Review | | 980 | 252-255 | Experimental Use | RFC xxxx | 981 +-----------+-------------------------------------------+-----------+ 982 Table 6: ICV Message TLV Type Extensions 984 More than one ICV Message TLV with the same type extension MAY be 985 included in a message if these represent different ICV calculations 986 (e.g., with type extension 1 or 2 and different cryptographic 987 function and/or hash function, or with a different key identifier). 988 ICV Message TLVs that carry what is declared to be the same 989 information MUST NOT be included in the same message. 991 13.8. TIMESTAMP Message TLV Type Extensions 993 IANA has, in accordance with [RFC6622], made allocations from the 994 "TIMESTAMP Message TLV Type Extensions" namespace of [RFC6622] for 995 the Message TLVs specified in Table 7. IANA is requested to modify 996 this allocation as indicated. 998 +-----------+-------------------------------------------+-----------+ 999 | Type | Description | Reference | 1000 | Extension | | | 1001 +-----------+-------------------------------------------+-----------+ 1002 | 0 | Unsigned timestamp of arbitrary length, | RFC xxxx | 1003 | | given by the TLV Length field. The MANET | | 1004 | | routing protocol has to define how to | | 1005 | | interpret this timestamp | | 1006 | 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx | 1007 | | in [IEEE 1003.1-2008 (POSIX)] | | 1008 | 2 | NTP timestamp format, as specified in | RFC xxxx | 1009 | | [RFC5905] | | 1010 | 3 | Signed timestamp of arbitrary length with | RFC xxxx | 1011 | | no constraints such as monotonicity. In | | 1012 | | particular, it may represent any random | | 1013 | | value | | 1014 | 4-251 | Unassigned; Expert Review | | 1015 | 252-255 | Experimental Use | RFC xxxx | 1016 +-----------+-------------------------------------------+-----------+ 1018 Table 7: TIMESTAMP Message TLV Type Extensions 1020 More than one TIMESTAMP Message TLV with the same type extension MUST 1021 NOT be included in a message. 1023 13.9. ICV Address Block TLV Type Extensions 1025 IANA has, in accordance with [RFC6622], made allocations from the 1026 "ICV Address Block TLV Type Extensions" namespace of [RFC6622] for 1027 the Address Block TLVs specified in Table 8. IANA is requested to 1028 modify this allocation (including defining type extension = 2) as 1029 indicated. 1031 +-----------+-------------------------------------------+-----------+ 1032 | Type | Description | Reference | 1033 | Extension | | | 1034 +-----------+-------------------------------------------+-----------+ 1035 | 0 | ICV of an object (e.g., an address) | RFC xxxx | 1036 | 1 | ICV, using a cryptographic function and a | RFC xxxx | 1037 | | hash function, as specified in Section 12 | | 1038 | | of this document | | 1039 | 2 | ICV, using a cryptographic function and a | RFC xxxx | 1040 | | hash function, and including the IP | | 1041 | | datagram source address, as specified in | | 1042 | | Section 12 of this document | | 1043 | 3-251 | Unassigned; Expert Review | | 1044 | 252-255 | Experimental Use | RFC xxxx | 1045 +-----------+-------------------------------------------+-----------+ 1047 Table 8: ICV Address Block TLV Type Extensions 1049 More than one ICV Address Block TLV with the same type extension MAY 1050 be associate with an address if these represent different ICV 1051 calculations (e.g., with type extension 1 or 2 and different 1052 cryptographic function and/or hash function, or with a different key 1053 identifier). ICV Address Block TLVs that carry what is declared to 1054 be the same information MUST NOT be associated with the same address. 1056 13.10. TIMESTAMP Address Block TLV Type Extensions 1058 IANA has, in accordance with [RFC6622], made allocations from the 1059 "TIMESTAMP Address Block TLV Type Extensions" namespace of [RFC6622] 1060 for the Address Block TLVs specified in Table 9. IANA is requested 1061 to modify this allocation as indicated. 1063 +-----------+-------------------------------------------+-----------+ 1064 | Type | Description | Reference | 1065 | Extension | | | 1066 +-----------+-------------------------------------------+-----------+ 1067 | 0 | Unsigned timestamp of arbitrary length, | RFC xxxx | 1068 | | given by the TLV Length field. The MANET | | 1069 | | routing protocol has to define how to | | 1070 | | interpret this timestamp | | 1071 | 1 | Unsigned 32-bit timestamp, as specified | RFC xxxx | 1072 | | in [IEEE 1003.1-2008 (POSIX)] | | 1073 | 2 | NTP timestamp format, as specified in | RFC xxxx | 1074 | | [RFC5905] | | 1075 | 3 | Signed timestamp of arbitrary length with | RFC xxxx | 1076 | | no constraints such as monotonicity. In | | 1077 | | particular, it may represent any random | | 1078 | | value | | 1079 | 4-251 | Unassigned; Expert Review | | 1080 | 252-255 | Experimental Use | RFC xxxx | 1081 +-----------+-------------------------------------------+-----------+ 1083 Table 9: TIMESTAMP Address Block TLV Type Extensions 1085 More than one TIMESTAMP Address Block TLV with the same type 1086 extension MUST NOT be associated with any address. 1088 13.11. Hash Functions 1090 IANA has, in accordance with [RFC6622], created a registry for hash 1091 functions that can be used when creating an ICV, as specified in 1092 Section 12 of this document. The initial assignments and allocation 1093 policies are specified in Table 10. IANA is requested to modify this 1094 allocation as indicated. 1096 +---------+-----------+---------------------------------+-----------+ 1097 | Value | Algorithm | Description | Reference | 1098 +---------+-----------+---------------------------------+-----------+ 1099 | 0 | none | The "identity function": The | RFC xxxx | 1100 | | | hash value of an object is the | | 1101 | | | object itself | | 1102 | 1 | SHA-1 | [NIST-FIPS-180-4] | RFC xxxx | 1103 | 2 | SHA-224 | [NIST-FIPS-180-4] | RFC xxxx | 1104 | 3 | SHA-256 | [NIST-FIPS-180-4] | RFC xxxx | 1105 | 4 | SHA-384 | [NIST-FIPS-180-4] | RFC xxxx | 1106 | 5 | SHA-512 | [NIST-FIPS-180-4] | RFC xxxx | 1107 | 6-251 | | Unassigned; Expert Review | | 1108 | 252-255 | | Experimental Use | RFC xxxx | 1109 +---------+-----------+---------------------------------+-----------+ 1111 Table 10: Hash Function Registry 1113 13.12. Cryptographic Functions 1115 IANA has, in accordance with [RFC6622], created a registry for the 1116 cryptographic functions, as specified in Section 12 of this document. 1117 Initial assignments and allocation policies are specified in 1118 Table 11. IANA is requested to modify this allocation as indicated. 1120 +---------+-----------+---------------------------------+-----------+ 1121 | Value | Algorithm | Description | Reference | 1122 +---------+-----------+---------------------------------+-----------+ 1123 | 0 | none | The "identity function": The | RFC xxxx | 1124 | | | value of an encrypted hash is | | 1125 | | | the hash itself | | 1126 | 1 | RSA | [RFC3447] | RFC xxxx | 1127 | 2 | DSA | [NIST-FIPS-186-4] | RFC xxxx | 1128 | 3 | HMAC | [RFC2104] | RFC xxxx | 1129 | 4 | 3DES | [NIST-SP-800-67] | RFC xxxx | 1130 | 5 | AES | [NIST-FIPS-197] | RFC xxxx | 1131 | 6 | ECDSA | [RFC6090] | RFC xxxx | 1132 | 7-251 | | Unassigned; Expert Review | | 1133 | 252-255 | | Experimental Use | RFC xxxx | 1134 +---------+-----------+---------------------------------+-----------+ 1136 Table 11: Cryptographic Function Registry 1138 14. Security Considerations 1140 This document does not specify a protocol. It provides a syntactical 1141 component for cryptographic ICVs of messages and packets, as defined 1142 in [RFC5444]. It can be used to address security issues of a MANET 1143 routing protocol or MANET routing protocol extension. As such, it 1144 has the same security considerations as [RFC5444]. 1146 In addition, a MANET routing protocol or MANET routing protocol 1147 extension that uses this specification MUST specify how to use the 1148 framework, and the TLVs presented in this document. In addition, the 1149 protection that the MANET routing protocol or MANET routing protocol 1150 extensions attain by using this framework MUST be described. 1152 As an example, a MANET routing protocol that uses this component to 1153 reject "badly formed" or "insecure" messages if a control message 1154 does not contain a valid ICV SHOULD indicate the security assumption 1155 that if the ICV is valid, the message is considered valid. It also 1156 SHOULD indicate the security issues that are counteracted by this 1157 measure (e.g., link or identity spoofing) as well as the issues that 1158 are not counteracted (e.g., compromised keys). 1160 15. Acknowledgements 1162 The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE 1163 Systems), Justin Dean (NRL), Paul Lambert (Marvell), Jerome Milan 1164 (Ecole Polytechnique), and Henning Rogge (FGAN) for their 1165 constructive comments on [RFC6622]. 1167 The authors also appreciate the detailed reviews of [RFC6622] from 1168 the Area Directors, in particular Stewart Bryant (Cisco), Stephen 1169 Farrell (Trinity College Dublin), and Robert Sparks (Tekelec), as 1170 well as Donald Eastlake (Huawei) from the Security Directorate. 1172 The authors would like to thank Justin Dean (NRL) and Henning Rogge 1173 (FGAN) for their constructive comments on this specification. 1175 16. References 1177 16.1. Normative References 1179 [BCP26] Narten, T. and H. Alvestrand, "Guidelines 1180 for Writing an IANA Considerations 1181 Section in RFCs", BCP 26, RFC 5226, 1182 May 2008. 1184 [NIST-FIPS-186-4] National Institute of Standards and 1185 Technology, "Digital Signature Standard 1186 (DSS)", FIPS 186-4, July 2013. 1188 [NIST-FIPS-197] National Institute of Standards and 1189 Technology, "Specification for the 1190 Advanced Encryption Standard (AES)", 1191 FIPS 197, November 2001. 1193 [NIST-SP-800-107] National Institute of Standards and 1194 Technology, "Recommendation for 1195 Applications Using Approved Hash 1196 Algorithms", SP 800-107, Revision 1, 1197 August 2012. 1199 [RFC2104] Krawczyk, H., Bellare, M., and R. 1200 Canetti, "HMAC: Keyed-Hashing for Message 1201 Authentication", RFC 2104, February 1997. 1203 [RFC2119] Bradner, S., "Key words for use in RFCs 1204 to Indicate Requirement Levels", BCP 14, 1205 RFC 2119, March 1997. 1207 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key 1208 Cryptography Standards (PKCS) #1: RSA 1209 Cryptography Specifications Version 2.1", 1210 RFC 3447, February 2003. 1212 [RFC4493] Song, JH., Poovendran, R., Lee, J., and 1213 T. Iwata, "The AES-CMAC Algorithm", 1214 RFC 4493, June 2006. 1216 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and 1217 C. Adjih, "Generalized Mobile Ad Hoc 1218 Network (MANET) Packet/Message Format", 1219 RFC 5444, February 2009. 1221 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., 1222 and W. Kasch, "Network Time Protocol 1223 Version 4: Protocol and Algorithms 1224 Specification", RFC 5905, June 2010. 1226 [RFC6090] McGrew, D., Igoe, K., and M. Salter, 1227 "Fundamental Elliptic Curve Cryptography 1228 Algorithms", RFC 6090, February 2011. 1230 [NIST-SP-800-67] National Institute of Standards and 1231 Technology, "Recommendation for the 1232 Triple Data Encryption Algorithm (TDEA) 1233 Block Cipher", Special 1234 Publication 800-67, Revision 1, 1235 January 2012. 1237 [NIST-FIPS-180-4] National Institute of Standards and 1238 Technology, "Secure Hash Standard (SHS)", 1239 FIPS 180-4, March 2012. 1241 [IEEE 1003.1-2008 (POSIX)] IEEE Computer Society, "1003.1-2008 1242 Standard for Information Technology - 1243 Portable Operating System Interface 1244 (POSIX) Base Specifications, Issue 7", 1245 December 2008. 1247 16.2. Informative References 1249 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, 1250 "Mobile Ad Hoc Network (MANET) 1251 Neighborhood Discovery Protocol (NHDP)", 1252 RFC 6130, April 2011. 1254 [RFC6622] Herberg, U. and T. Clausen, "Integrity 1255 Check Value and Timestamp TLV Definitions 1256 for Mobile Ad Hoc Networks (MANETs)", 1257 RFC 6622, May 2012. 1259 [OLSRv2] Clausen, T., Dearlove, C., Jacquet, P., 1260 and U. Herberg, "The Optimized Link State 1261 Routing Protocol version 2", work in 1262 progress draft-ietf-manet-olsrv2-19, 1263 March 2013. 1265 Authors' Addresses 1267 Ulrich Herberg 1268 Fujitsu Laboratories of America 1269 1240 E. Arques Ave. 1270 Sunnyvale, CA 94085 1271 USA 1273 EMail: ulrich@herberg.name 1274 URI: http://www.herberg.name/ 1276 Thomas Heide Clausen 1277 LIX, Ecole Polytechnique 1278 91128 Palaiseau Cedex 1279 France 1281 Phone: +33 6 6058 9349 1282 EMail: T.Clausen@computer.org 1283 URI: http://www.thomasclausen.org/ 1284 Christopher Dearlove 1285 BAE Systems Advanced Technology Centre 1286 West Hanningfield Road 1287 Great Baddow, Chelmsford 1288 United Kingdom 1290 Phone: +44 1245 242194 1291 EMail: chris.dearlove@baesystems.com 1292 URI: http://www.baesystems.com/