idnits 2.17.1 draft-ietf-manet-packetbb-sec-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5444]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 6, 2011) is 4606 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) == Outdated reference: A later version (-19) exists of draft-ietf-manet-olsrv2-12 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) U. Herberg 3 Internet-Draft Fujitsu Laboratories of America 4 Intended status: Standards Track T. Clausen 5 Expires: March 9, 2012 LIX, Ecole Polytechnique 6 September 6, 2011 8 MANET Cryptographical Signature TLV Definition 9 draft-ietf-manet-packetbb-sec-06 11 Abstract 13 This document describes general and flexible TLVs (type-length-value 14 structure) for representing cryptographic signatures as well as 15 timestamps, using the generalized MANET packet/message format 16 [RFC5444]. It defines two Packet TLVs, two Message TLVs, and two 17 Address Block TLVs, for affixing cryptographic signatures 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 March 9, 2012. 37 Copyright Notice 39 Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . 4 57 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4 58 5. Overview and Functioning . . . . . . . . . . . . . . . . . . . 5 59 6. General Signature TLV Structure . . . . . . . . . . . . . . . 6 60 7. General Timestamp TLV Structure . . . . . . . . . . . . . . . 6 61 8. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . . . . 7 63 8.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 7 64 9. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. Message SIGNATURE TLV . . . . . . . . . . . . . . . . . . 8 66 9.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 8 67 10. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Address Block SIGNATURE TLV . . . . . . . . . . . . . . . 8 69 10.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 9 70 11. Signature: Basic . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. Signature: Cryptographic Function over a Hash Value . . . . . 9 72 12.1. General Signature TLV Structure . . . . . . . . . . . . . 9 73 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 10 74 12.2. Considerations for Calculating the Signature . . . . . . . 11 75 12.2.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . 11 76 12.2.2. Message SIGNATURE TLV . . . . . . . . . . . . . . . . 11 77 12.2.3. Address Block SIGNATURE TLV . . . . . . . . . . . . . 11 78 12.3. Example of a Signed Message . . . . . . . . . . . . . . . 11 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 13.1. Expert Review: Evaluation Guidelines . . . . . . . . . . . 13 81 13.2. Packet TLV Type Registrations . . . . . . . . . . . . . . 13 82 13.3. Message TLV Type Registrations . . . . . . . . . . . . . . 14 83 13.4. Address Block TLV Type Registrations . . . . . . . . . . . 15 84 13.5. Hash Function . . . . . . . . . . . . . . . . . . . . . . 15 85 13.6. Cryptographic Algorithm . . . . . . . . . . . . . . . . . 16 86 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 87 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 89 16.1. Normative References . . . . . . . . . . . . . . . . . . . 17 90 16.2. Informative References . . . . . . . . . . . . . . . . . . 17 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 93 1. Introduction 95 This document specifies: 97 o two TLVs for carrying cryptographic signatures and timestamps in 98 packets, messages, and address blocks as defined by [RFC5444], 100 o a generic framework for calculating cryptographic signatures, 101 accounting (for Message TLVs) for mutable message header fields 102 ( and ), where these fields are 103 present in messages. 105 This document requests from IANA: 107 o allocations for these Packet, Message, and Address Block TLVs from 108 the 0-223 Packet TLV range, the 0-127 Message TLV range and the 109 0-127 Address Block TLV range from [RFC5444], 111 o creation of two IANA registries for recording code points for hash 112 function and signature calculation, respectively. 114 Finally, this document defines, in Section 12: 116 o one common method for generating signatures as a cryptographic 117 function, calculated over the hash value of the content to be 118 signed. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in 125 [RFC2119]. 127 This document uses the terminology and notation defined in [RFC5444]. 128 In particular, the following TLV fields from [RFC5444] are used in 129 this specification: 131 - hop limit of a message, as specified in Section 132 5.2 of [RFC5444]. 134 - hop count of a message, as specified in Section 135 5.2 of [RFC5444]. 137 - length of a TLV in octets, as specified in Section 5.4.1 138 of [RFC5444]. 140 3. Applicability Statement 142 MANET routing protocols using the format defined in [RFC5444] are 143 accorded the ability to carry additional information in control 144 messages and packets, through inclusion of TLVs. Information so 145 included MAY be used by a MANET routing protocol, or by an extension 146 of a MANET routing protocol, according to its specification. 148 This document specifies how to include a cryptographic signature for 149 a packet, a message, and addresses in address blocks within a 150 message, by way of such TLVs. This document also specifies how to 151 treat "mutable" fields, specifically the and fields, if present in the message header when calculating 153 signatures, such that the resulting signature can be correctly 154 verified by any recipient, and how to include this signature. 156 This document describes a generic framework for creating signatures, 157 and how to include these signatures in TLVs. In Section 12, an 158 example method for calculating such signatures is given, using a 159 cryptographic function over the hash value of the content to be 160 signed. 162 4. Security Architecture 164 Basic MANET routing protocol specifications are often "oblivious to 165 security", however have a clause allowing a control message to be 166 rejected as "badly formed" prior to it being processed or forwarded. 167 MANET routing protocols such as [RFC6130] and [OLSRv2] recognize 168 external reasons (such as failure to verify a signature) for 169 rejecting a message as "badly formed", and therefore "invalid for 170 processing". This architecture is a result of the observation that 171 with respect to security in MANETs, "one size rarely fits all" and 172 that MANET routing protocol deployment domains have varying security 173 requirements ranging from "unbreakable" to "virtually none". The 174 virtue of this approach is that MANET routing protocol specifications 175 (and implementations) can remain "generic", with extensions providing 176 proper deployment-domain specific security mechanisms. 178 The MANET routing protocol "security architecture", in which this 179 specification situates itself, can therefore be summarized as 180 follows: 182 o Security-oblivious MANET routing protocol specifications, with a 183 clause allowing an extension to reject a message (prior to 184 processing/forwarding) as "badly formed". 186 o MANET routing protocol security extensions, rejecting messages as 187 "badly formed", as appropriate for a given deployment-domain 188 specific security requirement. 190 o Code-points and an exchange format for information, necessary for 191 specification of such MANET routing protocol security extensions. 193 This document addresses the last of these issues, by specifying a 194 common exchange format for cryptographic signatures, making 195 reservations from within the Packet TLV, Message TLV, and Address 196 Block TLV registries of [RFC5444], to be used (and shared) among 197 MANET routing protocol security extensions. 199 For the specific decomposition of a signature into a cryptographic 200 function over a hash value, specified in Section 12, this document 201 establishes two IANA registries for code-points for hash functions 202 and cryptographic functions adhering to [RFC5444]. 204 With respect to [RFC5444], this document: 206 o is intended to be used in the non-normative, but intended, mode of 207 use described in Appendix B of [RFC5444]. 209 o is a specific example of the Security Considerations section of 210 [RFC5444] (the authentication part). 212 5. Overview and Functioning 214 This document specifies a syntactical representation of security 215 related information for use with [RFC5444] addresses, messages, and 216 packets, as well as establishes IANA registrations and registries. 218 Moreover, this document provides guidelines how MANET routing 219 protocols and MANET routing protocol extensions, using this 220 specification, should treat Signature and Timestamp TLVs, and mutable 221 fields in messages. This specification does not represent a stand- 222 alone protocol; MANET routing protocols and MANET routing protocol 223 extensions, using this specification, MUST provide instructions as to 224 how to handle packets, messages and addresses with security 225 information, associated as specified in this document. 227 This document requests assignment of TLV types from the registries 228 defined for Packet, Message and Address Block TLVs in [RFC5444]. 230 When a TLV type is assigned from one of these registries, a registry 231 for "Type Extensions" for that TLV type is created by IANA. This 232 document utilizes these "Type Extension" registries so created, in 233 order to specify internal structure (and accompanying processing) of 234 the field of a TLV. 236 For example, and as defined in this document, a SIGNATURE TLV with 237 Type Extension = 0 specifies that the field has no pre- 238 defined internal structure, but is simply a sequence of octets. A 239 SIGNATURE TLV with Type Extension = 1 specifies that the 240 field has a pre-defined internal structure, and defines its 241 interpretation (specifically, the field consists of a 242 cryptographic operation over a hash value, with fields indicating 243 which hash function and cryptographic operation has been used, 244 specified in Section 12). 246 Other documents may request assignments for other Type Extensions, 247 and must if so specify their internal structure (if any) and 248 interpretation. 250 6. General Signature TLV Structure 252 The value of the Signature TLV is: 254 := 256 where: 258 is a field, of octets, which contains the 259 information, to be interpreted by the signature verification 260 process, as specified by the Type Extension. 262 Note that this does not stipulate how to calculate the , nor the internal structure hereof, if any; such MUST be 264 specified by way of the Type Extension for the SIGNATURE TLV type, 265 see Section 13. This document specifies two such type-extensions, 266 for signatures without pre-defined structures, and for signatures 267 constructed by way of a cryptographic operation over a hash-value. 269 7. General Timestamp TLV Structure 271 The value of the Timestamp TLV is: 273 := 275 where: 277 is an unsigned integer field, of length , which 278 contains the timestamp. 280 Note that this does not stipulate how to calculate the , nor the internal structure hereof, if any; such MUST be 282 specified by way of the Type Extension for the TIMESTAMP TLV type, 283 see Section 13. 285 A timestamp is essentially "freshness information". As such, its 286 setting and interpretation is to be determined by the MANET routing 287 protocol, or MANET routing protocol extension, that uses the 288 timestamp, and may, e.g., correspond to a UNIX-timestamp, GPS 289 timestamp or a simple sequence number. 291 8. Packet TLVs 293 Two Packet TLVs are defined, for including the cryptographic 294 signature of a packet, and for including the timestamp indicating the 295 time at which the cryptographic signature was calculated. 297 8.1. Packet SIGNATURE TLV 299 A Packet SIGNATURE TLV is an example of a Signature TLV as described 300 in Section 6. 302 The following considerations apply: 304 o As packets defined in [RFC5444] are never forwarded by routers, no 305 special considerations are required regarding mutable fields (e.g. 306 and ), if present, when calculating 307 the signature. 309 o Any Packet SIGNATURE TLVs already present in the Packet TLV block 310 MUST be removed before calculating the signature, and the Packet 311 TLV block size MUST be recalculated accordingly. The TLVs can be 312 restored after having calculated the signature value. 314 The rationale for removing any Packet SIGNATURE TLV already present 315 prior to calculating the signature is that several signatures may be 316 added to the same packet, e.g., using different signature functions. 318 8.2. Packet TIMESTAMP TLV 320 A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described 321 in Section 7. If a packet contains a TIMESTAMP TLV and a SIGNATURE 322 TLV, the TIMESTAMP TLV SHOULD be added to the packet before any 323 SIGNATURE TLV, in order that it be included in the calculation of the 324 signature. 326 9. Message TLVs 328 Two Message TLVs are defined, for including the cryptographic 329 signature of a message, and for including the timestamp indicating 330 the time at which the cryptographic signature was calculated. 332 9.1. Message SIGNATURE TLV 334 A Message SIGNATURE TLV is an example of a Signature TLV as described 335 in Section 6. When determining the for a message, 336 the following considerations must be applied: 338 o The fields and , if present, MUST 339 both be assumed to have the value 0 (zero) when calculating the 340 signature. 342 o Any Message SIGNATURE TLVs already present in the Message TLV 343 block MUST be removed before calculating the signature, and the 344 message size as well as the Message TLV block size MUST be 345 recalculated accordingly. Removed SIGNATURE TLVs SHOULD be 346 restored after having calculated the signature value. 348 The rationale for removing any Message SIGNATURE TLV already present 349 prior to calculating the signature is that several signatures may be 350 added to the same message, e.g., using different signature functions. 352 9.2. Message TIMESTAMP TLV 354 A Message TIMESTAMP TLV is an example of a Timestamp TLV as described 355 in Section 7. If a message contains a TIMESTAMP TLV and a SIGNATURE 356 TLV, the TIMESTAMP TLV SHOULD be added to the message before the 357 SIGNATURE TLV, in order that it be included in the calculation of the 358 signature. 360 10. Address Block TLVs 362 Two Address Block TLVs are defined, for associating a cryptographic 363 signature to an address, and for including the timestamp indicating 364 the time at which the cryptographic signature was calculated. 366 10.1. Address Block SIGNATURE TLV 368 An Address Block SIGNATURE TLV is an example of a Signature TLV as 369 described in Section 6. The signature is calculated over the 370 address, concatenated with any other values, for example, any other 371 TLV value that is associated with that address. A MANET routing 372 protocol or MANET routing protocol extension using Address Block 373 SIGNATURE TLVs MUST specify how to include any such concatenated 374 attribute of the address in the verification process of the 375 signature. 377 10.2. Address Block TIMESTAMP TLV 379 An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as 380 described in Section 7. If both a TIMESTAMP TLV and a SIGNATURE TLV 381 are associated with an address, the timestamp value should be 382 considered when calculating the value of the signature. 384 11. Signature: Basic 386 The basic signature proposed, represented by way of a SIGNATURE TLV 387 with Type Extension = 0, is a simple bit-field containing the 388 cryptographic signature. This assumes that the mechanism stipulating 389 how signatures are calculated and verified is established outside of 390 this specification, e.g., by way of administrative configuration or 391 external out-of-band signaling. Thus, the for when 392 using Type Extension = 0 is: 394 := 396 where: 398 is an unsigned integer field, of length , 399 which contains the cryptographic signature. 401 12. Signature: Cryptographic Function over a Hash Value 403 One common way of calculating a signature is applying a cryptographic 404 function on a hash value of the content. This decomposition is 405 specified in the following, using a Type Extension = 1 in the 406 Signature TLVs. 408 12.1. General Signature TLV Structure 410 The following data structure allows representation of a cryptographic 411 signature, including specification of the appropriate hash function 412 and cryptographic function used for calculating the signature: 414 := 415 416 417 419 where: 421 is an 8-bit unsigned integer field specifying the 422 hash function. 424 is an 8-bit unsigned integer field 425 specifying the cryptographic function. 427 is an 8-bit unsigned integer field specifying the key 428 index of the key which was used to sign the message, which allows 429 unique identification of different keys with the same originator. 430 It is the responsibility of each key originator to make sure that 431 actively used keys that it issues have distinct key indices and 432 that all key indices have a value not equal to 0x00. The value 433 0x00 is reserved for a pre-installed, shared key. 435 is an unsigned integer field, whose length is 436 - 3, and which contains the cryptographic signature. 438 The version of this TLV, specified in this section, assumes that 439 calculating the signature can be decomposed into: 441 signature-value = cryptographic-function(hash-function(content)) 443 The hash function and the cryptographic function correspond to the 444 entries in two IANA registries, set up by this specification in 445 Section 13. 447 12.1.1. Rationale 449 The rationale for separating the hash function and the cryptographic 450 function into two octets instead of having all combinations in a 451 single octet - possibly as TLV type extension - is twofold: First, if 452 further hash functions or cryptographic functions are added in the 453 future, the number space might not remain continuous. More 454 importantly, the number space of possible combinations would be 455 rapidly exhausted. As new or improved cryptographic mechanism are 456 continuously being developed and introduced, this format should be 457 able to accommodate such for the foreseeable future. 459 The rationale for not including a field that lists parameters of the 460 cryptographic signature in the TLV is, that before being able to 461 validate a cryptographic signature, routers have to exchange or 462 acquire keys (e.g. public keys). Any additional parameters can be 463 provided together with the keys in that bootstrap process. It is 464 therefore not necessary, and would even entail an extra overhead, to 465 transmit the parameters within every message. One implicitly 466 available parameter is the length of the signature, which is 467 - 3, and which depends on the choice of the cryptographic function. 469 12.2. Considerations for Calculating the Signature 471 In the following, considerations are listed, which MUST be applied 472 when calculating the signature for Packet, Message and Address 473 SIGNATURE TLVs, respectively. 475 12.2.1. Packet SIGNATURE TLV 477 When determining the for a Packet, the signature is 478 calculated over the three fields , and (in that order), concatenated with the 480 entire Packet, including the packet header, all Packet TLVs (other 481 than Packet SIGNATURE TLVs) and all included Messages and their 482 message headers, in accordance with Section 8.1. 484 12.2.2. Message SIGNATURE TLV 486 When determining the for a message, the signature 487 is calculated over the three fields , , and (in that order), concatenated with the 489 entire message. The considerations in Section 9.1 MUST be applied. 491 12.2.3. Address Block SIGNATURE TLV 493 When determining the for an address, the signature 494 is calculated over the three fields , , and (in that order), concatenated with the 496 address, concatenated with any other values, for example, any other 497 TLV value that is associated with that address. A MANET routing 498 protocol or MANET routing protocol extension using Address Block 499 SIGNATURE TLVs MUST specify how to include any such concatenated 500 attribute of the address in the verification process of the 501 signature. The considerations in Section 10.2 MUST be applied. 503 12.3. Example of a Signed Message 505 The sample message depicted in Figure 1 is derived from appendix D of 506 [RFC5444]. The message contains a SIGNATURE Message TLV, with the 507 value representing a 16 octet long signature of the whole message. 508 The type extension of the Message TLV is 1, for the specific 509 decomposition of a signature into a cryptographic function over a 510 hash value, as specified in Section 12. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | PV=0 | PF=8 | Packet Sequence Number | Message Type | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | MF=15 | MAL=3 | Message Length = 40 | Msg. Orig Addr| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 | Message Originator Address (cont) | Hop Limit | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | Hop Count | Message Sequence Number | Msg. TLV Block| 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Length = 30 | SIGNATURE | MTLVF = 144 | MTLVExt = 1 | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 |Value Len = 19 | Hash Func | Crypto Func | Key Index | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Signature Value | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Signature Value (cont) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Signature Value (cont) | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Signature Value (cont) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 Figure 1: Example message with signature 538 13. IANA Considerations 540 This specification defines: 542 o two Packet TLV types, which MUST be allocated from the 0-223 range 543 of the "Assigned Packet TLV Types" repository of [RFC5444] as 544 specified in Table 1, 546 o two Message TLV types, which MUST be allocated from the 0-127 547 range of the "Assigned Message TLV Types" repository of [RFC5444] 548 as specified in Table 2, 550 o two Address Block TLV types, which MUST be allocated from the 551 0-127 range of the "Assigned Address Block TLV Types" repository 552 of [RFC5444] as specified in Table 3. 554 This specification requests: 556 o creation of type extension registries for these TLV types with 557 initial values as in Table 1 to Table 3. 559 IANA is requested to assign the same numerical value to the Packet 560 TLV, Message TLV and Address Block TLV types with the same name. 562 The following terms are used with the meanings defined in [BCP26]: 563 "Namespace", "Assigned Value", "Registration", "Unassigned", 564 "Reserved", "Hierarchical Allocation", and "Designated Expert". 566 The following policies are used with the meanings defined in [BCP26]: 567 "Private Use", "Expert Review", and "Standards Action". 569 13.1. Expert Review: Evaluation Guidelines 571 For the registries for TLV type extensions where an Expert Review is 572 required, the designated expert SHOULD take the same general 573 recommendations into consideration as are specified by [RFC5444]. 575 For the Timestamp TLV, the same type extensions for all Packet, 576 Message and Address TLVs SHOULD be numbered identically. 578 13.2. Packet TLV Type Registrations 580 IANA is requested to make allocations from the "Packet TLV Types" 581 namespace of [RFC5444] for the Packet TLVs specified in Table 1. 583 +-----------+------+-----------+------------------------------------+ 584 | Name | Type | Type | Description | 585 | | | Extension | | 586 +-----------+------+-----------+------------------------------------+ 587 | SIGNATURE | TBD1 | 0 | Signature of a packet | 588 | | | 1 | Signature, decomposed into | 589 | | | | cryptographic function over a hash | 590 | | | | value, as specified in Section 12 | 591 | | | | in this document. | 592 | | | 2-223 | Expert Review | 593 | | | 224-255 | Experimental Use | 594 | TIMESTAMP | TBD2 | 0 | Unsigned timestamp of arbitrary | 595 | | | | length, given by the TLV length | 596 | | | | field. The MANET routing protocol | 597 | | | | has to define how to interpret | 598 | | | | this timestamp | 599 | | | 1-223 | Expert Review | 600 | | | 224-255 | Experimental Use | 601 +-----------+------+-----------+------------------------------------+ 603 Table 1: Packet TLV types 605 13.3. Message TLV Type Registrations 607 IANA is requested to make allocations from the "Message TLV Types" 608 namespace of [RFC5444] for the Message TLVs specified in Table 2. 610 +-----------+------+-----------+------------------------------------+ 611 | Name | Type | Type | Description | 612 | | | Extension | | 613 +-----------+------+-----------+------------------------------------+ 614 | SIGNATURE | TBD3 | 0 | Signature of a message | 615 | | | 1 | Signature, decomposed into | 616 | | | | cryptographic function over a hash | 617 | | | | value, as specified in Section 12 | 618 | | | | in this document. | 619 | | | 2-223 | Expert Review | 620 | | | 224-255 | Experimental Use | 621 | TIMESTAMP | TBD4 | 0 | Unsigned timestamp of arbitrary | 622 | | | | length, given by the TLV length | 623 | | | | field. | 624 | | | 1-223 | Expert Review | 625 | | | 224-255 | Experimental Use | 626 +-----------+------+-----------+------------------------------------+ 628 Table 2: Message TLV types 630 13.4. Address Block TLV Type Registrations 632 IANA is requested to make allocations from the "Address Block TLV 633 Types" namespace of [RFC5444] for the Packet TLVs specified in 634 Table 3. 636 +-----------+------+-----------+------------------------------------+ 637 | Name | Type | Type | Description | 638 | | | Extension | | 639 +-----------+------+-----------+------------------------------------+ 640 | SIGNATURE | TBD5 | 0 | Signature of an object (e.g. an | 641 | | | | address) | 642 | | | 1 | Signature, decomposed into | 643 | | | | cryptographic function over a hash | 644 | | | | value, as specified in Section 12 | 645 | | | | in this document. | 646 | | | 2-223 | Expert Review | 647 | | | 224-255 | Experimental Use | 648 | TIMESTAMP | TBD6 | 0 | Unsigned timestamp of arbitrary | 649 | | | | length, given by the TLV length | 650 | | | | field. | 651 | | | 1-223 | Expert Review | 652 | | | 224-255 | Experimental Use | 653 +-----------+------+-----------+------------------------------------+ 655 Table 3: Address Block TLV types 657 13.5. Hash Function 659 IANA is requested to create a new registry for hash functions that 660 can be used when creating a signature, as specified in Section 12 of 661 this document. The initial assignments and allocation policies are 662 specified in Table 4. 664 +-------------+-----------+-----------------------------------------+ 665 | Hash | Algorithm | Description | 666 | function | | | 667 | value | | | 668 +-------------+-----------+-----------------------------------------+ 669 | 0 | none | The "identity function": the hash value | 670 | | | of an object is the object itself | 671 | 1-223 | | Expert Review | 672 | 224-255 | | Experimental Use | 673 +-------------+-----------+-----------------------------------------+ 675 Table 4: Hash-Function registry 677 13.6. Cryptographic Algorithm 679 IANA is requested to create a new registry for the cryptographic 680 function, as specified in Section 12 of this document. Initial 681 assignments and allocation policies are specified in Table 5. 683 +----------------+-----------+--------------------------------------+ 684 | Cryptographic | Algorithm | Description | 685 | function value | | | 686 +----------------+-----------+--------------------------------------+ 687 | 0 | none | The "identity function": the value | 688 | | | of an encrypted hash is the hash | 689 | | | itself | 690 | 1-223 | | Expert Review | 691 | 224-255 | | Experimental Use | 692 +----------------+-----------+--------------------------------------+ 694 Table 5: Cryptographic function registry 696 14. Security Considerations 698 This document does not specify a protocol. It provides a syntactical 699 component for cryptographic signatures of messages and packets as 700 defined in [RFC5444]. It can be used to address security issues of a 701 MANET routing protocol or MANET routing protocol extension. As such, 702 it has the same security considerations as [RFC5444]. 704 In addition, a MANET routing protocol or MANET routing protocol 705 extension that uses this specification MUST specify the usage as well 706 as the security that is attained by the cryptographic signatures of a 707 message or a packet. 709 As an example, a MANET routing protocol that uses this component to 710 reject "badly formed" messages if a control message does not contain 711 a valid signature, SHOULD indicate the security assumption that if 712 the signature is valid, the message is considered valid. It also 713 SHOULD indicate the security issues that are counteracted by this 714 measure (e.g. link or identity spoofing) as well as the issues that 715 are not counteracted (e.g. compromised keys). 717 15. Acknowledgements 719 The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE), 720 Justin Dean (NRL), Christopher Dearlove (BAE), Paul Lambert 721 (Marvell), Jerome Milan (Ecole Polytechnique) and Henning Rogge 722 (FGAN) for their constructive comments on the document. 724 16. References 726 16.1. Normative References 728 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 729 IANA Considerations Section in RFCs", RFC 5226, BCP 26, 730 May 2008. 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", RFC 2119, BCP 14, March 1997. 735 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 736 "Generalized MANET Packet/Message Format", RFC 5444, 737 February 2009. 739 16.2. Informative References 741 [OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized 742 Link State Routing Protocol version 2", work in 743 progress draft-ietf-manet-olsrv2-12.txt, July 2011. 745 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET 746 Neighborhood Discovery Protocol (NHDP)", RFC 6130, 747 March 2011. 749 Authors' Addresses 751 Ulrich Herberg 752 Fujitsu Laboratories of America 753 1240 E. Arques Ave. M/S 345 754 Sunnyvale, CA, 94085 755 USA 757 Email: ulrich@herberg.name 758 URI: http://www.herberg.name/ 760 Thomas Heide Clausen 761 LIX, Ecole Polytechnique 762 91128 Palaiseau Cedex, 763 France 765 Phone: +33 6 6058 9349 766 Email: T.Clausen@computer.org 767 URI: http://www.thomasclausen.org/