idnits 2.17.1 draft-ietf-manet-packetbb-sec-04.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 (July 11, 2011) is 4673 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-11 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 T. Clausen 4 Intended status: Standards Track LIX, Ecole Polytechnique 5 Expires: January 12, 2012 July 11, 2011 7 MANET Cryptographical Signature TLV Definition 8 draft-ietf-manet-packetbb-sec-04 10 Abstract 12 This document describes general and flexible TLVs (type-length-value 13 structure) for representing cryptographic signatures as well as 14 timestamps, using the generalized MANET packet/message format 15 [RFC5444]. It defines two Packet TLVs, two Message TLVs, and two 16 Address Block TLVs, for affixing cryptographic signatures and 17 timestamps to a packet, message and address, respectively. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 12, 2012. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 56 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4 57 5. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 58 6. Imported TLV Fields . . . . . . . . . . . . . . . . . . . . . 5 59 7. General Signature TLV Structure . . . . . . . . . . . . . . . 5 60 8. General Timestamp TLV Structure . . . . . . . . . . . . . . . 6 61 9. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 9.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . . . . 6 63 9.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 7 64 10. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 10.1. Message SIGNATURE TLV . . . . . . . . . . . . . . . . . . 7 66 10.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 7 67 11. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 8 68 11.1. Address Block SIGNATURE TLV . . . . . . . . . . . . . . . 8 69 11.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 8 70 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 12.1. TLV Registrations . . . . . . . . . . . . . . . . . . . . 8 72 12.1.1. Expert Review: Evaluation Guidelines . . . . . . . . 9 73 12.1.2. Packet TLV Type Registrations . . . . . . . . . . . . 9 74 12.1.3. Message TLV Type Registrations . . . . . . . . . . . 9 75 12.1.4. Address Block TLV Type Registrations . . . . . . . . 10 76 12.2. New IANA Registries . . . . . . . . . . . . . . . . . . . 11 77 12.2.1. Expert Review: Evaluation Guidelines . . . . . . . . 11 78 12.2.2. Hash Function . . . . . . . . . . . . . . . . . . . . 11 79 12.2.3. Cryptographic Algorithm . . . . . . . . . . . . . . . 11 80 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 82 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 84 15.2. Informative References . . . . . . . . . . . . . . . . . . 13 85 Appendix A. Signature Decomposition into Cryptographic 86 Function of a Hash Value . . . . . . . . . . . . . . 13 87 A.1. General Signature TLV Structure . . . . . . . . . . . . . 13 88 A.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 89 A.2. Considerations for Calculating the Signature . . . . . . . 15 90 A.2.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . 15 91 A.2.2. Message SIGNATURE TLV . . . . . . . . . . . . . . . . 15 92 A.2.3. Address Block SIGNATURE TLV . . . . . . . . . . . . . 15 93 A.3. Example of a Signed Message . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 98 This document specifies: 100 o two TLVs for carrying cryptographic signatures and timestamps in 101 packets, messages and address blocks as defined by [RFC5444], 103 o a generic framework for calculating cryptographic signatures, 104 taking (for Message TLVs) into account the mutable message header 105 fields ( and ) where these fields 106 are present in messages, 108 o a specific calculation of signatures, decomposed as a 109 cryptographic function over the hash value of the content to be 110 signed, in the Appendix A of this document. 112 This document requests from IANA: 114 o allocations for these Packet, Message, and Address Block TLVs from 115 the 0-223 Packet TLV range, the 0-127 Message TLV range and the 116 0-127 Address Block TLV range from [RFC5444], 118 o creation of two IANA registries for recording code points for hash 119 function and signature calculation, respectively. 121 2. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. 128 This document uses the terminology and notation defined in [RFC5444]. 130 3. Applicability Statement 132 MANET routing protocols using the format defined in [RFC5444] are 133 accorded the ability to carry additional information in control 134 messages and packets, through inclusion of TLVs. Information so 135 included MAY be used by a routing protocol, or by an extension of a 136 routing protocol, according to its specification. 138 This document specifies how to include a cryptographic signature for 139 a packet, message or address by way of such TLVs. This document also 140 specifies how to treat "mutable" fields ( and ), if present, in the message header when calculating 142 signatures, such that the resulting signature can be correctly 143 verified by any recipient, and how to include this signature. 145 This document is split into two parts: (i) a generic framework of 146 creating signatures in the presence of mutable fields, and how to 147 include these signatures in TLVs, (ii) a specific description of how 148 to calculate a signature, using a cryptographic function over the 149 hash value of the content to be signed, in the Appendix A of this 150 document. Note that (ii) is a possible and widely-used way of 151 calculating a signature, but other means may exist. Such other means 152 of calculating a signature have to be specified in another document. 153 That new document MUST use the TLV structures specified in this 154 document, as well as the described considerations when calculating 155 the signatures. 157 4. Security Architecture 159 Basic MANET routing protocol specifications are often "oblivious to 160 security", however have a clause allowing a control message to be 161 rejected as "badly formed" prior to it being processed or forwarded. 162 Protocols such as [RFC6130] and [OLSRv2] recognize external reasons 163 (such as failure to verify a signature) for rejecting a message as 164 "badly formed", and therefore "invalid for processing". This 165 architecture is a result of the observation that with respect to 166 security in MANETs, "one size rarely fits all" and that MANET routing 167 protocol deployment domains have varying security requirements 168 ranging from "unbreakable" to "virtually none". The virtue of this 169 approach is that MANET routing protocol specifications (and 170 implementations) can remain "generic", with extensions providing 171 proper deployment-domain specific security mechanisms. 173 The MANET routing protocol "security architecture", in which this 174 specification situates itself, can therefore be summarized as 175 follows: 177 o Security-oblivious MANET routing protocol specifications, with a 178 clause allowing an extension to reject a message (prior to 179 processing/forwarding) as "badly formed". 181 o MANET routing protocol security extensions, rejecting messages as 182 "badly formed", as appropriate for a given deployment-domain 183 specific security requirement. 185 o Code-points and an exchange format for information, necessary for 186 specification of such MANET routing protocol security extensions. 188 This document addresses the last of these issues, by specifying a 189 common exchange format for cryptographic signatures, making 190 reservations from within the Packet TLV, Message TLV and Address 191 Block TLV registries of [RFC5444], to be used (and shared) among 192 MANET routing protocol security extensions. 194 For the specific decomposition of a signature into a cryptographic 195 function over a hash value, specified in Appendix A, this document 196 establishes two IANA registries for code-points for hash functions 197 and cryptographic functions adhering to [RFC5444]. 199 With respect to [RFC5444], this document: 201 o is intended to be used in the non-normative, but intended, mode of 202 use of [RFC5444] as described in its Appendix B. 204 o is a specific example of the Security Considerations section of 205 [RFC5444] (the authentication part). 207 5. Protocol Overview and Functioning 209 This specification does not describe a protocol, nor does it mandate 210 specific router or protocol behavior. It represents a purely 211 syntactical representation of security related information for use 212 with [RFC5444] addresses, messages and packets, as well as 213 establishes IANA registrations and registries. 215 6. Imported TLV Fields 217 In this specification, the following TLV fields from [RFC5444] are 218 used: 220 - hop limit of a message, as specified in Section 221 5.2 of [RFC5444]. 223 - hop count of a message, as specified in Section 224 5.2 of [RFC5444]. 226 - length of a TLV in octets, as specified in Section 5.4.1 227 of [RFC5444]. 229 7. General Signature TLV Structure 231 The following data structure allows a generic representation of a 232 cryptographic signature. This data structure is 233 specified, using the regular expression syntax of [RFC5444], as: 235 := 237 This generic specification allows for adding a signature in a TLV, 238 using TLV type extension 0, and does not stipulate how to calculate 239 the signature-value. Appendix A specifies a concrete calculation of 240 the signature-value, using a cryptographic function over a hash 241 function of the content to be signed. Other methods of how to 242 calculate the signature-value may be specified in future documents. 244 8. General Timestamp TLV Structure 246 The following data structure allows the representation of a 247 timestamp. This data structure is specified as: 249 := 251 where: 253 is an unsigned integer field, whose length is , 254 and which contains the timestamp. The value of this variable is 255 to be interpreted by the routing protocol as specified by the type 256 extension of the Timestamp TLV, see Section 12. 258 A timestamp is essentially "freshness information". As such, its 259 setting and interpretation is to be determined by the routing 260 protocol (or the extension to a routing protocol) that uses it, and 261 may e.g. correspond to a UNIX-timestamp, GPS timestamp or a simple 262 sequence number. 264 9. Packet TLVs 266 Two Packet TLVs are defined, for including the cryptographic 267 signature of a packet, and for including the timestamp indicating the 268 time at which the cryptographic signature was calculated. 270 9.1. Packet SIGNATURE TLV 272 A Packet SIGNATURE TLV is an example of a Signature TLV as described 273 in Section 7. 275 The following considerations apply: 277 o As packets defined in [RFC5444] are never forwarded by routers, it 278 is unnecessary to consider mutable fields (e.g. 279 and ), if present, when calculating the signature. 281 o any Packet SIGNATURE TLVs already present in the Packet TLV block 282 MUST be removed before calculating the signature, and the Packet 283 TLV block size MUST be recalculated accordingly. The TLVs can be 284 restored after having calculated the signature value. 286 The rationale for removing any Packet SIGNATURE TLV already present 287 prior to calculating the signature, is that several signatures may be 288 added to the same packet, e.g., using different signature functions. 290 9.2. Packet TIMESTAMP TLV 292 A Packet TIMESTAMP TLV is an example of a Timestamp TLV as described 293 in Section 8. If a packet contains a TIMESTAMP TLV and a SIGNATURE 294 TLV, the TIMESTAMP TLV SHOULD be added to the packet before any 295 SIGNATURE TLV, in order that it be included in the calculation of the 296 signature. 298 10. Message TLVs 300 Two Message TLVs are defined, for including the cryptographic 301 signature of a message, and for including the timestamp indicating 302 the time at which the cryptographic signature was calculated. 304 10.1. Message SIGNATURE TLV 306 A Message SIGNATURE TLV is an example of a Signature TLV as described 307 in Section 7. When determining the for a message, 308 the following considerations must be applied: 310 o the fields and , if present, MUST 311 both be assumed to have the value 0 (zero) when calculating the 312 signature. 314 o any Message SIGNATURE TLVs already present in the Message TLV 315 block MUST be removed before calculating the signature, and the 316 message size as well as the Message TLV block size MUST be 317 recalculated accordingly. The TLVs can be restored after having 318 calculated the signature value. 320 The rationale for removing any Message SIGNATURE TLV already present 321 prior to calculating the signature, is that several signatures may be 322 added to the same message, e.g., using different signature functions. 324 10.2. Message TIMESTAMP TLV 326 A Message TIMESTAMP TLV is an example of a Timestamp TLV as described 327 in Section 8. If a message contains a TIMESTAMP TLV and a SIGNATURE 328 TLV, the TIMESTAMP TLV SHOULD be added to the message before the 329 SIGNATURE TLV, in order that it be included in the calculation of the 330 signature. 332 11. Address Block TLVs 334 Two Address Block TLVs are defined, for associating a cryptographic 335 signature to an address, and for including the timestamp indicating 336 the time at which the cryptographic signature was calculated. 338 11.1. Address Block SIGNATURE TLV 340 An Address Block SIGNATURE TLV is an example of a Signature TLV as 341 described in Section 7. The signature is calculated over the 342 address, concatenated with any other values, for example, any other 343 TLV value that is associated with that address. A routing protocol 344 or routing protocol extension using Address Block SIGNATURE TLVs MUST 345 specify how to include any such concatenated attribute of the address 346 in the verification process of the signature. 348 11.2. Address Block TIMESTAMP TLV 350 An Address Block TIMESTAMP TLV is an example of a Timestamp TLV as 351 described in Section 8. If both a TIMESTAMP TLV and a SIGNATURE TLV 352 are associated with an address, the timestamp value should be 353 considered when calculating the value of the signature. 355 12. IANA Considerations 357 This section specifies requests to IANA. 359 12.1. TLV Registrations 361 This specification defines: 363 o two Packet TLV types which must be allocated from the 0-223 range 364 of the "Assigned Packet TLV Types" repository of [RFC5444] as 365 specified in Table 1, 367 o two Message TLV types which must be allocated from the 0-127 range 368 of the "Assigned Message TLV Types" repository of [RFC5444] as 369 specified in Table 2, 371 o and two Address Block TLV types which must be allocated from the 372 0-127 range of the "Assigned Address Block TLV Types" repository 373 of [RFC5444] as specified in Table 3. 375 This specification requests: 377 o set up of type extension registries for these TLV types. 379 IANA is requested to assign the same numerical value to the Packet 380 TLV, Message TLV and Address Block TLV types with the same name. 382 12.1.1. Expert Review: Evaluation Guidelines 384 For the registries for TLV type extensions where an Expert Review is 385 required, the designated expert SHOULD take the same general 386 recommendations into consideration as are specified by [RFC5444]. 388 For the Timestamp TLV, the same type extensions for all Packet, 389 Message and Address TLVs should be numbered identically. 391 12.1.2. Packet TLV Type Registrations 393 The Packet TLVs as specified in Table 1 must be allocated from the 394 "Packet TLV Types" namespace of [RFC5444]. 396 +-----------+------+-----------+------------------------------------+ 397 | Name | Type | Type | Description | 398 | | | Extension | | 399 +-----------+------+-----------+------------------------------------+ 400 | SIGNATURE | TBD1 | 0 | Signature of a packet | 401 | | | 1 | Signature, decomposed into | 402 | | | | cryptographic function over a hash | 403 | | | | value, as specified in Appendix A | 404 | | | | in this document. | 405 | | | 2-223 | Expert Review | 406 | | | 224-255 | Experimental Use | 407 | TIMESTAMP | TBD2 | 0 | Unsigned timestamp of arbitrary | 408 | | | | length, given by the TLV length | 409 | | | | field. The MANET routing protocol | 410 | | | | has to define how to interpret | 411 | | | | this timestamp | 412 | | | 1-223 | Expert Review | 413 | | | 224-255 | Experimental Use | 414 +-----------+------+-----------+------------------------------------+ 416 Table 1: Packet TLV types 418 12.1.3. Message TLV Type Registrations 420 The Message TLVs as specified in Table 2 must be allocated from the 421 "Message TLV Types" namespace of [RFC5444]. 423 +-----------+------+-----------+------------------------------------+ 424 | Name | Type | Type | Description | 425 | | | Extension | | 426 +-----------+------+-----------+------------------------------------+ 427 | SIGNATURE | TBD3 | 0 | Signature of a message | 428 | | | 1 | Signature, decomposed into | 429 | | | | cryptographic function over a hash | 430 | | | | value, as specified in Appendix A | 431 | | | | in this document. | 432 | | | 2-223 | Expert Review | 433 | | | 224-255 | Experimental Use | 434 | TIMESTAMP | TBD4 | 0 | Unsigned timestamp of arbitrary | 435 | | | | length, given by the TLV length | 436 | | | | field. | 437 | | | 1-223 | Expert Review | 438 | | | 224-255 | Experimental Use | 439 +-----------+------+-----------+------------------------------------+ 441 Table 2: Message TLV types 443 12.1.4. Address Block TLV Type Registrations 445 The Address Block TLVs as specified in Table 3 must be allocated from 446 the "Address Block TLV Types" namespace of [RFC5444]. 448 +-----------+------+-----------+------------------------------------+ 449 | Name | Type | Type | Description | 450 | | | Extension | | 451 +-----------+------+-----------+------------------------------------+ 452 | SIGNATURE | TBD5 | 0 | Signature of an object (e.g. an | 453 | | | | address) | 454 | | | 1 | Signature, decomposed into | 455 | | | | cryptographic function over a hash | 456 | | | | value, as specified in Appendix A | 457 | | | | in this document. | 458 | | | 2-223 | Expert Review | 459 | | | 224-255 | Experimental Use | 460 | TIMESTAMP | TBD6 | 0 | Unsigned timestamp of arbitrary | 461 | | | | length, given by the TLV length | 462 | | | | field. | 463 | | | 1-223 | Expert Review | 464 | | | 224-255 | Experimental Use | 465 +-----------+------+-----------+------------------------------------+ 467 Table 3: Address Block TLV types 469 12.2. New IANA Registries 471 This document introduces three namespaces that have been registered: 472 Packet TLV Types, Message TLV Types, and Address Block TLV Types. 473 This section specifies IANA registries for these namespaces and 474 provides guidance to the Internet Assigned Numbers Authority 475 regarding registrations in these namespaces. 477 The following terms are used with the meanings defined in [BCP26]: 478 "Namespace", "Assigned Value", "Registration", "Unassigned", 479 "Reserved", "Hierarchical Allocation", and "Designated Expert". 481 The following policies are used with the meanings defined in [BCP26]: 482 "Private Use", "Expert Review", and "Standards Action". 484 12.2.1. Expert Review: Evaluation Guidelines 486 For the registries for the following tables where an Expert Review is 487 required, the designated expert SHOULD take the same general 488 recommendations into consideration as are specified by [RFC5444]. 490 12.2.2. Hash Function 492 IANA is requested to create a new registry for the hash functions 493 that can be used when creating a signature, as specified in the 494 Appendix A of this document. The initial assignments and allocation 495 policies are specified in Table 4. 497 +-------------+-----------+-----------------------------------------+ 498 | Hash | Algorithm | Description | 499 | function | | | 500 | value | | | 501 +-------------+-----------+-----------------------------------------+ 502 | 0 | none | The "identity function": the hash value | 503 | | | of an object is the object itself | 504 | 1-223 | | Expert Review | 505 | 224-255 | | Experimental Use | 506 +-------------+-----------+-----------------------------------------+ 508 Table 4: Hash-Function registry 510 12.2.3. Cryptographic Algorithm 512 IANA is requested to create a new registry for the cryptographic 513 function, as specified in the Appendix A of this document. Initial 514 assignments and allocation policies are specified in Table 5. 516 +----------------+-----------+--------------------------------------+ 517 | Cryptographic | Algorithm | Description | 518 | function value | | | 519 +----------------+-----------+--------------------------------------+ 520 | 0 | none | The "identity function": the value | 521 | | | of an encrypted hash is the hash | 522 | | | itself | 523 | 1-223 | | Expert Review | 524 | 224-255 | | Experimental Use | 525 +----------------+-----------+--------------------------------------+ 527 Table 5: Cryptographic function registry 529 13. Security Considerations 531 This document does not specify a protocol itself. However, it 532 provides a syntactical component for cryptographic signatures of 533 messages and packets as defined in [RFC5444]. It can be used to 534 address security issues of a protocol or extension that uses the 535 component specified in this document. As such, it has the same 536 security considerations as [RFC5444]. 538 In addition, a protocol that includes this component MUST specify the 539 usage as well as the security that is attained by the cryptographic 540 signatures of a message or a packet. 542 As an example, a routing protocol that uses this component to reject 543 "badly formed" messages if a control message does not contain a valid 544 signature, should indicate the security assumption that if the 545 signature is valid, the message is considered valid. It also should 546 indicate the security issues that are counteracted by this measure 547 (e.g. link or identity spoofing) as well as the issues that are not 548 counteracted (e.g. compromised keys). 550 14. Acknowledgements 552 The authors would like to thank Jerome Milan (Ecole Polytechnique) 553 for his advice as cryptographer. In addition, many thanks to Bo 554 Berry (Cisco), Alan Cullen (BAE), Justin Dean (NRL), Christopher 555 Dearlove (BAE), Paul Lambert (Marvell), and Henning Rogge (FGAN) for 556 their constructive comments on the document. 558 15. References 559 15.1. Normative References 561 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 562 IANA Considerations Section in RFCs", RFC 5226, BCP 26, 563 May 2008. 565 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 566 Requirement Levels", RFC 2119, BCP 14, March 1997. 568 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 569 "Generalized MANET Packet/Message Format", RFC 5444, 570 February 2009. 572 15.2. Informative References 574 [OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized 575 Link State Routing Protocol version 2", work in 576 progress draft-ietf-manet-olsrv2-11.txt, April 2010. 578 [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET 579 Neighborhood Discovery Protocol (NHDP)", RFC 6130, 580 March 2011. 582 Appendix A. Signature Decomposition into Cryptographic Function of a 583 Hash Value 585 This section specifies how to calculate the signature-value in a 586 Signature TLV, as described in Section 7. A common way of 587 calculating a signature is applying a cryptographic function on a 588 hash value of the content. This decomposition is specified in the 589 following, using a type extension of 1 in the Signature TLVs. 591 A.1. General Signature TLV Structure 593 The following data structure allows representation of a cryptographic 594 signature, including specification of the appropriate hash function 595 and cryptographic function used for calculating the signature: 597 := 598 599 600 602 where: 604 is an 8-bit unsigned integer field specifying the 605 hash function. 607 is an 8-bit unsigned integer field 608 specifying the cryptographic function. 610 is an 8-bit unsigned integer field specifying the key 611 index of the key which was used to sign the message, which allows 612 unique identification of different keys with the same originator. 613 It is the responsibility of each key originator to make sure that 614 actively used keys that it issues have distinct key indices and 615 that all key indices have a value unequal to 0x00. Value 0x00 is 616 reserved for a pre-installed, shared key. 618 is an unsigned integer field, whose length is 619 - 3, and which contains the cryptographic signature. 621 The version of this TLV, specified in this section, assumes that 622 calculating the signature can be decomposed into: 624 signature-value = cryptographic-function(hash-function(content)) 626 The hash function and the cryptographic function correspond to the 627 entries in two IANA registries, set up by this specification in 628 Section 12. 630 A.1.1. Rationale 632 The rationale for separating the hash function and the cryptographic 633 function into two octets instead of having all combinations in a 634 single octet - possibly as TLV type extension - is twofold: First, if 635 further hash functions or cryptographic functions are added in the 636 future, the number space might not remain continuous. More 637 importantly, the number space of possible combinations would be 638 rapidly exhausted. As new or improved cryptographic mechanism are 639 continuously being developed and introduced, this format should be 640 able to accommodate such for the foreseeable future. 642 The rationale for not including a field that lists parameters of the 643 cryptographic signature in the TLV is, that before being able to 644 validate a cryptographic signature, routers have to exchange or 645 acquire keys (e.g. public keys). Any additional parameters can be 646 provided together with the keys in that bootstrap process. It is 647 therefore not necessary, and would even entail an extra overhead, to 648 transmit the parameters within every message. One inherently 649 included parameter is the length of the signature, which is 650 - 3 and which depends on the choice of the cryptographic function. 652 A.2. Considerations for Calculating the Signature 654 In the following, considerations are listed, which have to be applied 655 when calculating the signature for Packet, Message and Address 656 SIGNATURE TLVs, respectively. 658 A.2.1. Packet SIGNATURE TLV 660 When determining the for a Packet, the signature is 661 calculated over the three fields , and (in that order), concatenated with the 663 entire Packet, including the packet header, all Packet TLVs (other 664 than Packet SIGNATURE TLVs) and all included Messages and their 665 message headers. 667 A.2.2. Message SIGNATURE TLV 669 When determining the for a message, the signature 670 is calculated over the three fields , , and (in that order), concatenated with the 672 entire message. 674 A.2.3. Address Block SIGNATURE TLV 676 When determining the for an address, the signature 677 is calculated over the three fields , , and (in that order), concatenated with the 679 address, concatenated with any other values, for example, any other 680 TLV value that is associated with that address. A routing protocol 681 or routing protocol extension using Address Block SIGNATURE TLVs MUST 682 specify how to include any such concatenated attribute of the address 683 in the verification process of the signature. 685 A.3. Example of a Signed Message 687 The sample message depicted in Figure 1 is derived from the appendix 688 of [RFC5444]. A SIGNATURE Message TLV has been added, with the value 689 representing a 14 octet long signature of the whole message. The 690 type extension of the Message TLV is 1, for the specific 691 decomposition of a signature into a cryptographic function over a 692 hash value, as specified in Appendix A. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 |1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0| Orig Addr | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Originator Address (cont) | Hop Limit | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 |0 0 0 1 1 1 1 0| SIGNATURE |1 0 0 1 0 0 0 0|0 0 0 0 0 0 0 1| 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |0 0 0 1 0 0 1 0| Hash Func | Crypto Func | Key Index | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Signature Value | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Signature Value (cont) | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Signature Value (cont) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Signature Value (cont) | TLV Type |0 0 0 1 0 0 0 0| 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 |0 0 0 0 0 1 1 0| Value | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Value (cont) |0 0 0 0 0 0 1 0| 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 |0 0 1 1 0 0 0 0|0 0 0 0 0 0 1 0| Mid | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Mid | Prefix Length |0 0 0 0 0 0 0 0| 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0| 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Head | Mid | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Mid | Mid | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0| 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 |0 0 0 0 0 0 1 0| Value | TLV Type | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 |0 0 1 0 0 0 0 0| Index Start | Index Stop | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 1: Example message with signature 740 Authors' Addresses 742 Ulrich Herberg 743 LIX, Ecole Polytechnique 744 91128 Palaiseau Cedex, 745 France 747 Phone: +33 1 6933 4126 748 Email: ulrich@herberg.name 749 URI: http://www.herberg.name/ 751 Thomas Heide Clausen 752 LIX, Ecole Polytechnique 753 91128 Palaiseau Cedex, 754 France 756 Phone: +33 6 6058 9349 757 Email: T.Clausen@computer.org 758 URI: http://www.thomasclausen.org/