idnits 2.17.1 draft-ietf-manet-packetbb-sec-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 31, 2012) is 4468 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-13 Summary: 1 error (**), 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: August 3, 2012 LIX, Ecole Polytechnique 6 January 31, 2012 8 MANET Cryptographical Signature TLV Definition 9 draft-ietf-manet-packetbb-sec-08 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 defined 16 in RFC 5444. 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 August 3, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 9 69 10.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 9 70 11. Signature: Basic . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. Signature: Cryptographic Function over a Hash Value . . . . . 10 72 12.1. General Signature TLV Structure . . . . . . . . . . . . . 10 73 12.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12 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 for 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 can 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 can, 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. Removed 312 SIGNATURE TLVs SHOULD be restored after having calculated the 313 signature value. 315 The rationale for removing any Packet SIGNATURE TLV already present 316 prior to calculating the signature is that several signatures may be 317 added to the same packet, e.g., using different signature functions. 319 8.2. Packet TIMESTAMP TLV 321 A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described 322 in Section 7. If a packet contains a TIMESTAMP TLV and a SIGNATURE 323 TLV, the TIMESTAMP TLV SHOULD be added to the packet before any 324 SIGNATURE TLV, in order that it be included in the calculation of the 325 signature. 327 9. Message TLVs 329 Two Message TLVs are defined, for including the cryptographic 330 signature of a message, and for including the timestamp indicating 331 the time at which the cryptographic signature was calculated. 333 9.1. Message SIGNATURE TLV 335 A Message SIGNATURE TLV is an example of a Signature TLV as described 336 in Section 6. When determining the for a message, 337 the following considerations MUST be applied: 339 o The fields and , if present, MUST 340 both be assumed to have the value 0 (zero) when calculating the 341 signature. 343 o Any Message SIGNATURE TLVs already present in the Message TLV 344 block MUST be removed before calculating the signature, and the 345 message size as well as the Message TLV block size MUST be 346 recalculated accordingly. Removed SIGNATURE TLVs SHOULD be 347 restored after having calculated the signature value. 349 The rationale for removing any Message SIGNATURE TLV already present 350 prior to calculating the signature is that several signatures may be 351 added to the same message, e.g., using different signature functions. 353 9.2. Message TIMESTAMP TLV 355 A Message TIMESTAMP TLV is an example of a Timestamp TLV as described 356 in Section 7. If a message contains a TIMESTAMP TLV and a SIGNATURE 357 TLV, the TIMESTAMP TLV SHOULD be added to the message before the 358 SIGNATURE TLV, in order that it be included in the calculation of the 359 signature. 361 10. Address Block TLVs 363 Two Address Block TLVs are defined, for associating a cryptographic 364 signature to an address, and for including the timestamp indicating 365 the time at which the cryptographic signature was calculated. 367 10.1. Address Block SIGNATURE TLV 369 An Address Block SIGNATURE TLV is an example of a Signature TLV as 370 described in Section 6. The signature is calculated over the 371 address, concatenated with any other values, for example, any other 372 address block TLV fields, that is associated with that 373 address. A MANET routing protocol or MANET routing protocol 374 extension using Address Block SIGNATURE TLVs MUST specify how to 375 include any such concatenated attribute of the address in the 376 verification process of the signature. When determining the 377 for an address, the following consideration MUST be 378 applied: 380 o If other TLV values are concatenated with the address for 381 calculating the signature, these TLVs MUST NOT be Address Block 382 SIGNATURE TLVs already associated with the address. 384 The rationale for not concatenating the address with any SIGNATURE 385 TLV values already associated with the address when calculating the 386 signature is that several signatures may be added to the same 387 address, e.g., using different signature functions. 389 10.2. Address Block TIMESTAMP TLV 391 An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as 392 described in Section 7. If both a TIMESTAMP TLV and a SIGNATURE TLV 393 are associated with an address, the TIMESTAMP TLV SHOULD be 394 considered when calculating the value of the signature. 396 11. Signature: Basic 398 The basic signature, represented by way of a SIGNATURE TLV with Type 399 Extension = 0, is a simple bit-field containing the cryptographic 400 signature. This assumes that the mechanism stipulating how 401 signatures are calculated and verified is established outside of this 402 specification, e.g., by way of administrative configuration or 403 external out-of-band signaling. Thus, the for when 404 using Type Extension = 0 is: 406 := 408 where: 410 is an unsigned integer field, of length , 411 which contains the cryptographic signature. 413 12. Signature: Cryptographic Function over a Hash Value 415 One common way of calculating a signature is applying a cryptographic 416 function on a hash value of the content. This decomposition is 417 specified in the following, using a Type Extension = 1 in the 418 Signature TLVs. 420 12.1. General Signature TLV Structure 422 The following data structure allows representation of a cryptographic 423 signature, including specification of the appropriate hash function 424 and cryptographic function used for calculating the signature: 426 := 427 428 429 431 where: 433 is an 8-bit unsigned integer field specifying the 434 hash function. 436 is an 8-bit unsigned integer field 437 specifying the cryptographic function. 439 is an 8-bit unsigned integer field specifying the key 440 index of the key which was used to sign the message, which allows 441 unique identification of different keys with the same originator. 442 It is the responsibility of each key originator to make sure that 443 actively used keys that it issues have distinct key indices and 444 that all key indices have a value not equal to 0x00. The value 445 0x00 is reserved for a pre-installed, shared key. 447 is an unsigned integer field, whose length is 448 - 3, and which contains the cryptographic signature. 450 The version of this TLV, specified in this section, assumes that 451 calculating the signature can be decomposed into: 453 signature-value = cryptographic-function(hash-function(content)) 455 The hash function and the cryptographic function correspond to the 456 entries in two IANA registries, set up by this specification in 457 Section 13. 459 12.1.1. Rationale 461 The rationale for separating the hash function and the cryptographic 462 function into two octets instead of having all combinations in a 463 single octet - possibly as TLV type extension - is that adding 464 further hash functions or cryptographic functions in the future may 465 lead to a non-contiguous number space. 467 The rationale for not including a field that lists parameters of the 468 cryptographic signature in the TLV is that, before being able to 469 validate a cryptographic signature, routers have to exchange or 470 acquire keys (e.g. public keys). Any additional parameters can be 471 provided together with the keys in that bootstrap process. It is 472 therefore not necessary, and would even entail an extra overhead, to 473 transmit the parameters within every message. One implicitly 474 available parameter is the length of the signature, which is 475 - 3, and which depends on the choice of the cryptographic function. 477 12.2. Considerations for Calculating the Signature 479 In the following, considerations are listed, which MUST be applied 480 when calculating the signature for Packet, Message and Address 481 SIGNATURE TLVs, respectively. 483 12.2.1. Packet SIGNATURE TLV 485 When determining the for a Packet, the signature is 486 calculated over the three fields , and (in that order), concatenated with the 488 entire Packet, including the packet header, all Packet TLVs (other 489 than Packet SIGNATURE TLVs) and all included Messages and their 490 message headers, in accordance with Section 8.1. 492 12.2.2. Message SIGNATURE TLV 494 When determining the for a message, the signature 495 is calculated over the three fields , , and (in that order), concatenated with the 497 entire message. The considerations in Section 9.1 MUST be applied. 499 12.2.3. Address Block SIGNATURE TLV 501 When determining the for an address, the signature 502 is calculated over the three fields , , and (in that order), concatenated with the 504 address, concatenated with any other values, for example, any other 505 address block TLV that is associated with that address. A 506 MANET routing protocol or MANET routing protocol extension using 507 Address Block SIGNATURE TLVs MUST specify how to include any such 508 concatenated attribute of the address in the verification process of 509 the signature. The considerations in Section 10.2 MUST be applied. 511 12.3. Example of a Signed Message 513 The sample message depicted in Figure 1 is derived from appendix D of 514 [RFC5444]. The message contains a SIGNATURE Message TLV, with the 515 value representing a 16 octet long signature of the whole message. 516 The type extension of the Message TLV is 1, for the specific 517 decomposition of a signature into a cryptographic function over a 518 hash value, as specified in Section 12. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | PV=0 | PF=8 | Packet Sequence Number | Message Type | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | MF=15 | MAL=3 | Message Length = 40 | Msg. Orig Addr| 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Message Originator Address (cont) | Hop Limit | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Hop Count | Message Sequence Number | Msg. TLV Block| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Length = 30 | SIGNATURE | MTLVF = 144 | MTLVExt = 1 | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |Value Len = 19 | Hash Func | Crypto Func | Key Index | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Signature Value | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Signature Value (cont) | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | Signature Value (cont) | 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Signature Value (cont) | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 1: Example message with signature 546 13. IANA Considerations 548 This specification defines: 550 o Two Packet TLV types, which must be allocated from the 0-223 range 551 of the "Assigned Packet TLV Types" repository of [RFC5444] as 552 specified in Table 1, 554 o Two Message TLV types, which must be allocated from the 0-127 555 range of the "Assigned Message TLV Types" repository of [RFC5444] 556 as specified in Table 2, 558 o Two Address Block TLV types, which must be allocated from the 559 0-127 range of the "Assigned Address Block TLV Types" repository 560 of [RFC5444] as specified in Table 3. 562 This specification requests: 564 o Creation of type extension registries for these TLV types with 565 initial values as in Table 1 to Table 3. 567 IANA is requested to assign the same numerical value to the Packet 568 TLV, Message TLV and Address Block TLV types with the same name. 570 The following terms are used with the meanings defined in [BCP26]: 571 "Namespace", "Assigned Value", "Registration", "Unassigned", 572 "Reserved", "Hierarchical Allocation", and "Designated Expert". 574 The following policies are used with the meanings defined in [BCP26]: 575 "Private Use", "Expert Review", and "Standards Action". 577 13.1. Expert Review: Evaluation Guidelines 579 For the registries for TLV type extensions where an Expert Review is 580 required, the designated expert SHOULD take the same general 581 recommendations into consideration as are specified by [RFC5444]. 583 For the Timestamp TLV, the same type extensions for all Packet, 584 Message and Address Block TLVs SHOULD be numbered identically. 586 13.2. Packet TLV Type Registrations 588 IANA is requested to make allocations from the "Packet TLV Types" 589 namespace of [RFC5444] for the Packet TLVs specified in Table 1. 591 +-----------+------+-----------+------------------------------------+ 592 | Name | Type | Type | Description | 593 | | | Extension | | 594 +-----------+------+-----------+------------------------------------+ 595 | SIGNATURE | TBD1 | 0 | Signature of a packet | 596 | | | 1 | Signature, decomposed into | 597 | | | | cryptographic function over a hash | 598 | | | | value, as specified in Section 12 | 599 | | | | in this document. | 600 | | | 2-251 | Expert Review | 601 | | | 252-255 | Experimental Use | 602 | TIMESTAMP | TBD2 | 0 | Unsigned timestamp of arbitrary | 603 | | | | length, given by the TLV length | 604 | | | | field. The MANET routing protocol | 605 | | | | has to define how to interpret | 606 | | | | this timestamp | 607 | | | 1-251 | Expert Review | 608 | | | 252-255 | Experimental Use | 609 +-----------+------+-----------+------------------------------------+ 611 Table 1: Packet TLV types 613 13.3. Message TLV Type Registrations 615 IANA is requested to make allocations from the "Message TLV Types" 616 namespace of [RFC5444] for the Message TLVs specified in Table 2. 618 +-----------+------+-----------+------------------------------------+ 619 | Name | Type | Type | Description | 620 | | | Extension | | 621 +-----------+------+-----------+------------------------------------+ 622 | SIGNATURE | TBD3 | 0 | Signature of a message | 623 | | | 1 | Signature, decomposed into | 624 | | | | cryptographic function over a hash | 625 | | | | value, as specified in Section 12 | 626 | | | | in this document. | 627 | | | 2-251 | Expert Review | 628 | | | 252-255 | Experimental Use | 629 | TIMESTAMP | TBD4 | 0 | Unsigned timestamp of arbitrary | 630 | | | | length, given by the TLV length | 631 | | | | field. | 632 | | | 1-251 | Expert Review | 633 | | | 252-255 | Experimental Use | 634 +-----------+------+-----------+------------------------------------+ 636 Table 2: Message TLV types 638 13.4. Address Block TLV Type Registrations 640 IANA is requested to make allocations from the "Address Block TLV 641 Types" namespace of [RFC5444] for the Packet TLVs specified in 642 Table 3. 644 +-----------+------+-----------+------------------------------------+ 645 | Name | Type | Type | Description | 646 | | | Extension | | 647 +-----------+------+-----------+------------------------------------+ 648 | SIGNATURE | TBD5 | 0 | Signature of an object (e.g. an | 649 | | | | address) | 650 | | | 1 | Signature, decomposed into | 651 | | | | cryptographic function over a hash | 652 | | | | value, as specified in Section 12 | 653 | | | | in this document. | 654 | | | 2-251 | Expert Review | 655 | | | 252-255 | Experimental Use | 656 | TIMESTAMP | TBD6 | 0 | Unsigned timestamp of arbitrary | 657 | | | | length, given by the TLV length | 658 | | | | field. | 659 | | | 1-251 | Expert Review | 660 | | | 252-255 | Experimental Use | 661 +-----------+------+-----------+------------------------------------+ 663 Table 3: Address Block TLV types 665 13.5. Hash Function 667 IANA is requested to create a new registry for hash functions that 668 can be used when creating a signature, as specified in Section 12 of 669 this document. The initial assignments and allocation policies are 670 specified in Table 4. 672 +-------------+-----------+-----------------------------------------+ 673 | Hash | Algorithm | Description | 674 | function | | | 675 | value | | | 676 +-------------+-----------+-----------------------------------------+ 677 | 0 | none | The "identity function": the hash value | 678 | | | of an object is the object itself | 679 | 1-251 | | Expert Review | 680 | 252-255 | | Experimental Use | 681 +-------------+-----------+-----------------------------------------+ 683 Table 4: Hash-Function registry 685 13.6. Cryptographic Algorithm 687 IANA is requested to create a new registry for the cryptographic 688 function, as specified in Section 12 of this document. Initial 689 assignments and allocation policies are specified in Table 5. 691 +----------------+-----------+--------------------------------------+ 692 | Cryptographic | Algorithm | Description | 693 | function value | | | 694 +----------------+-----------+--------------------------------------+ 695 | 0 | none | The "identity function": the value | 696 | | | of an encrypted hash is the hash | 697 | | | itself | 698 | 1-251 | | Expert Review | 699 | 252-255 | | Experimental Use | 700 +----------------+-----------+--------------------------------------+ 702 Table 5: Cryptographic function registry 704 14. Security Considerations 706 This document does not specify a protocol. It provides a syntactical 707 component for cryptographic signatures of messages and packets as 708 defined in [RFC5444]. It can be used to address security issues of a 709 MANET routing protocol or MANET routing protocol extension. As such, 710 it has the same security considerations as [RFC5444]. 712 In addition, a MANET routing protocol or MANET routing protocol 713 extension that uses this specification MUST specify the usage as well 714 as the security that is attained by the cryptographic signatures of a 715 message or a packet. 717 As an example, a MANET routing protocol that uses this component to 718 reject "badly formed" messages if a control message does not contain 719 a valid signature, SHOULD indicate the security assumption that if 720 the signature is valid, the message is considered valid. It also 721 SHOULD indicate the security issues that are counteracted by this 722 measure (e.g. link or identity spoofing) as well as the issues that 723 are not counteracted (e.g. compromised keys). 725 15. Acknowledgements 727 The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE), 728 Justin Dean (NRL), Christopher Dearlove (BAE), Paul Lambert 729 (Marvell), Jerome Milan (Ecole Polytechnique) and Henning Rogge 730 (FGAN) for their constructive comments on the document. 732 16. References 734 16.1. Normative References 736 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 737 IANA Considerations Section in RFCs", RFC 5226, BCP 26, 738 May 2008. 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", RFC 2119, BCP 14, March 1997. 743 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 744 "Generalized MANET Packet/Message Format", RFC 5444, 745 February 2009. 747 16.2. Informative References 749 [OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized 750 Link State Routing Protocol version 2", work in 751 progress draft-ietf-manet-olsrv2-13.txt, October 2011. 753 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET 754 Neighborhood Discovery Protocol (NHDP)", RFC 6130, 755 March 2011. 757 Authors' Addresses 759 Ulrich Herberg 760 Fujitsu Laboratories of America 761 1240 E. Arques Ave. 762 Sunnyvale, CA, 94085 763 USA 765 Email: ulrich@herberg.name 766 URI: http://www.herberg.name/ 768 Thomas Heide Clausen 769 LIX, Ecole Polytechnique 770 91128 Palaiseau Cedex, 771 France 773 Phone: +33 6 6058 9349 774 Email: T.Clausen@computer.org 775 URI: http://www.thomasclausen.org/