idnits 2.17.1 draft-ietf-manet-ibs-05.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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 21, 2016) is 2957 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networking (MANET) C. Dearlove 3 Internet-Draft BAE Systems Applied Intelligence 4 Intended status: Experimental Laboratories 5 Expires: September 22, 2016 March 21, 2016 7 Identity-Based Signatures for MANET Routing Protocols 8 draft-ietf-manet-ibs-05 10 Abstract 12 This document extends RFC7182, which specifies a framework for, and 13 specific examples of, integrity check values (ICVs) for packets and 14 messages using the generalized packet/message format specified in 15 RFC5444. It does so by defining an additional cryptographic function 16 that allows the creation of an ICV that is an identity-based 17 signature, defined according to the ECCSI (Elliptic Curve-Based 18 Certificateless Signatures for Identity-Based Encryption) algorithm 19 specified in RFC6507. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 22, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 58 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Cryptographic Function . . . . . . . . . . . . . . . . . . 5 60 4.2. ECCSI parameters . . . . . . . . . . . . . . . . . . . . . 6 61 4.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 6.1. Experimental Status . . . . . . . . . . . . . . . . . . . 9 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 69 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 1. Introduction 74 [RFC7182] defines ICV (integrity check value) TLVs for use in packets 75 and messages that use the generalized MANET packet/message format 76 defined in [RFC5444]. This specification extends the TLV definitions 77 therein by defining two new cryptographic function code points from 78 within the registries set up by [RFC7182]. This allows the use of an 79 identity-based signature (IBS) as an ICV. An IBS has an additional 80 property that is not shared by all of the previously specified ICVs, 81 it not only indicates that the protected packet or message is valid, 82 but also verifies the originator of the packet/message. 84 This specification assumes that each router (i.e., each originator of 85 [RFC5444] format packets/messages) has an identity that may be tied 86 to the packet or message. The router may have more than one 87 identity, but will only use one for each ICV TLV. The cryptographic 88 strength of the IBS is not dependent on the choice of identity. 90 Two options for the choice of identity are supported (as reflected by 91 the two code points allocated). In the first the identity can be any 92 octet sequence (up to 255 octets) included in the ICV TLV. In the 93 second, the octet sequence is preceded by an address, either the IP 94 source address for a packet TLV, or the message originator address 95 for a message or address block TLV. In particular, the second option 96 allows just the address to be used as an identity. 98 Identity-based signatures allow identifying the originator of 99 information in a packet or message. They thus allow additional 100 security functions, such as revocation of an identity, and removing 101 all information with a specific originator, if this is recorded - as 102 it is for OLSRv2 [RFC7181], an expected user of this specification. 103 When applied to messages (rather than packets) this can significantly 104 reduce the damage that a compromised router can inflict on the 105 network. 107 Identity-based signatures are based on forms of asymmetric (public 108 key) cryptography - identity-based encryption (IBE). Compared to 109 symmetric cryptographic methods (such as HMAC and AES), IBE and IBS 110 methods avoid requiring a shared secret key that results in a single 111 point of failure vulnerability. Compared to more widely used 112 asymmetric (public key) cryptographic methods (such as RSA and 113 ECDSA), IBE and IBS methods have a major advantage, and a major 114 disadvantage. 116 The advantage referred to is that each router can be configured once 117 (for its key lifetime) by a trusted authority, independently of all 118 other routers. Thus a router can connect to the authority (typically 119 in a secure environment) to receive a private key, or can have a 120 private key delivered securely (out of band) from the authority. 121 During normal operation of the MANET, there is no need for the 122 trusted authority to be connected to the MANET, or even to still 123 exist. Additional routers can be authorized, with no reference to 124 previously authorized routers (the trusted authority must still exist 125 in this case). A router's public key is its identity, which when 126 tied to a packet or message (as is the case when using an address as, 127 or as part of, the identity) means that there is no need for public 128 key certificates or a certificate authority, and a router need not 129 retain key material for any other routers. 131 The disadvantage referred to is that the trusted authority has 132 complete authority, even more so than a conventional certificate 133 authority. Routers cannot generate their own private keys, only the 134 trusted authority can do that. Through the master secret held by the 135 trusted authority, it could impersonate any router (existing or not). 136 When used for identity-based encryption (not part of this 137 specification) the trusted authority can decrypt anything. However, 138 note that the shared secret key options described in [RFC7182] also 139 have this limitation. 141 There are alternative mathematical realizations of identity-based 142 signatures. This specification uses one that has been previously 143 published as [RFC6507], known as ECCSI (Elliptic Curve-Based 144 Certificateless Signatures for Identity-Based Encryption). In common 145 with other identity-based encryption/signature approaches, it is 146 based on the use of elliptic curves. Unlike some, it does not use 147 "pairings" (bilinear maps from a product of two elliptic curve groups 148 to another group). It thus may be easier to implement, and more 149 efficient, than some alternatives, although with a greater signature 150 size than some. This specification allows the use of any elliptic 151 curve that may be used by [RFC6507]. 153 The computational load imposed by ECCSI (and, perhaps more so, other 154 IBS methods) is not trivial, though depending significantly on the 155 quality of implementation of the required elliptic curve and other 156 mathematical functions. For a security level of 128 bits, the ICV 157 data length is 129 octets, which is longer than for alternative ICVs 158 specified in [RFC7182] (e.g., 32 octets for the similar strength 159 HMAC-SHA-256). The signature format used could have been slightly 160 shortened (to 97 octets) by using a compressed representation of an 161 elliptic curve point, however at the expense of some additional work 162 when verifying a signature, and loss of direct compatibility with 163 [RFC6507], and implementations thereof. 165 The trusted authority is referred to in [RFC6507] as the KMS (Key 166 Management Service). That term will be used in the rest of this 167 specification. 169 2. Terminology 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in 174 [RFC2119]. 176 Additionally, this document uses the terminology of [RFC5444], 177 [RFC6507], and [RFC7182]. 179 3. Applicability Statement 181 This specification adds an additional option to the framework 182 specified in [RFC7182] for use by [RFC5444] formatted packets and 183 messages. It is applicable as described in [RFC7182], and subject to 184 the additional comments in Section 6, particularly regarding the role 185 of the trusted authority (KMS). 187 Specific examples of protocols for which this specification is 188 suitable are NHDP [RFC6130] and OLSRv2 [RFC7181]. 190 4. Specification 192 4.1. Cryptographic Function 194 This specification defines a cryptographic function named ECCSI that 195 is implemented as specified as the "sign" function in Section 5.2.1 196 of [RFC6507]. To use that specification: 198 o The ICV is not calculated as cryptographic-function(hash- 199 function(content)) as defined in [RFC7182], but (like the HMAC 200 ICVs defined in [RFC7182]) uses the hash function within the 201 cryptographic function. The option "none" is not permitted for 202 hash-function, and the hash function must have a known fixed 203 length of N octets, as specified in Section 4.2. 205 o M in [RFC6507] is "content" as specified in in [RFC7182]. 207 o ID, used in [RFC6507], is as specified in Section 4.3. 209 o KPAK, SSK and PVT, used in [RFC6507], are as specified in Sections 210 4.2 and 5.1.1 of [RFC6507], provided by the KMS. 212 The length of the signature is 4N+1 octets, as specified in 213 [RFC6507], whose affine coordinate format (including an octet valued 214 0x04 to identify this) is used unchanged. 216 Verification of the ICV is not implemented by the receiver 217 recalculating the ICV and comparing with the received ICV, as it is 218 necessarily incapable of doing so. Instead the receiver evaluates 219 the "verify" function described in Section 5.2.2 of [RFC6507], which 220 may pass or fail. 222 To use that function M, KPAK, SSK and PVT are as specified above, 223 while ID is deduced from the received packet or message, as specified 224 in Section 4.3, using the element in the . This 225 element need not match that used by the receiver, and thus when using 226 this cryptographic function, multiple ICV TLVs differing only in 227 their , or in the choice of cryptographic function from the 228 two defined in this specification, SHOULD NOT be used unless routers 229 are administratively configured to recognize which to verify. 231 Routers MAY be administratively configured to reject a packet or 232 message ICV TLV using ECCSI based on part or all of ; for 233 example if this encodes a time after which this identity is no longer 234 valid, as described in Section 4.3. 236 4.2. ECCSI parameters 238 Section 4.1 of [RFC6507] specifies parameters n, N, p, E, B, G, and 239 q. The first of these, n, is specified as "A security parameter; the 240 size in bits of the prime p over which elliptic curve cryptography is 241 to be performed." For typical security levels (e.g., 128, 192 and 242 256 bits), n must be at least twice the required bits of security, 243 see Section 5.6.1 of [NIST-SP-800-57]. 245 Selection of an elliptic curve, and all related parameters, MUST be 246 by administrative means, and known to all routers. This 247 specification follows [RFC6507] with a RECOMMENDED selection to 248 follow Appendix D.1.2 of [NIST-FIPS-186-4]. (Note that n in that 249 document is q in [RFC6507].) However an alternative curve MAY be 250 used. 252 The parameter that is required by this specification is N, which is 253 defined as Ceiling(n/8). The hash function used must create an 254 output of size N octets. In particular for 128 bit security, and 255 hence n = 256, N = 32, and the RECOMMENDED hash function is SHA-256. 256 The signature (i.e. ) length is 4N + 1 octets, i.e., 129 257 octets for N = 32. 259 Note: [RFC6507] actually refers to the predecessor to 260 [NIST-FIPS-186-4], but the latest version is specified here; there 261 are no significant differences in this regard. 263 4.3. Identity 265 There are two options for the identity ID used by [RFC6507], which 266 are indicated by there being two code points allocated for this 267 cryptographic function, see Section 5. 269 o For the cryptographic function ECCSI, ID is the element 270 defined in Section 12.1 of [RFC7182]. This MUST NOT be empty. 272 o For the cryptographic function ECCSI-ADDR, ID is the concatenation 273 of an address (in network byte order) and the element 274 defined in Section 12.1 of [RFC7182], where the latter MAY be 275 empty. 277 * For a packet TLV this address is the IP source address of the 278 IP datagram in which this packet is included. 280 * For a message TLV or an address block TLV this address is the 281 message originator address (the element defined 282 in [RFC5444]) if that address is present, if not present and 283 the message is known to have travelled only one hop, then the 284 IP source address of the IP datagram in which this message is 285 included is used, otherwise no address is defined and the 286 message MUST be rejected. (Note that HELLO messages specified 287 in NHDP [RFC6130] and used in OLSRv2 [RFC7181] always only 288 travel one hop, and hence their IP source address SHOULD be 289 used if no originator address is present.) 291 The element MAY be (for the cryptographic function ECCSI- 292 ADDR) or include (for either cryptographic function) a representation 293 of the identity expiry time. This MAY use one of the representations 294 of time defined for the TIMESTAMP TLV in [RFC7182]. A RECOMMENDED 295 approach is to use the cryptographic function ECCSI-ADDR with element 296 containing the single octet representing the type of the 297 time, normally used as the TIMESTAMP TLV Type Extension, defined in 298 [RFC7182] Table 9, or any extension thereof, followed by the time as 299 so represented, normally used as the TIMESTAMP TLV Value. 301 Note that the identity is formatted by [RFC6507], and thus does not 302 need a length field incorporated into it by this specification. 304 5. IANA Considerations 306 IANA has, in accordance with [RFC7182], defined a registry 307 "Cryptographic Functions" under "Mobile Ad Hoc NETwork Parameters". 308 IANA is requested to make two new allocations from this registry, and 309 modify the unassigned range, as indicated. 311 +-------+------------+------------------------------+---------------+ 312 | Value | Algorithm | Description | Reference | 313 +-------+------------+------------------------------+---------------+ 314 | 7 | ECCSI | ECCSI [RFC6507] | This | 315 | | | | specification | 316 | 8 | ECCSI-ADDR | ECCSI [RFC6507] with an | This | 317 | | | address (source or | specification | 318 | | | originator) joined to | | 319 | | | identity | | 320 | 9-251 | | Unassigned; Expert Review | | 321 +-------+------------+------------------------------+---------------+ 323 Table 1: Cryptographic Function Registry 325 6. Security Considerations 327 This specification extends the security framework for MANET routing 328 protocols specified in [RFC7182] by the addition of an additional 329 cryptographic function, in two forms according to how identity is 330 specified. 332 This cryptographic function implements a form of identity-based 333 signature (IBS), a stronger form of integrity check value (ICV) that 334 verifies not just that the received packet or message is valid but 335 that the packet or message originated at a router that was assigned a 336 private key for the specified identity. 338 It is recommended that the identity includes an address unique to 339 that router; for a message its originator address, for a packet the 340 corresponding IP packet source address. If additional information is 341 included in the identity this may be to indicate an expiry time for 342 signatures created using that identity. 344 In common with other forms of IBS, a feature of the form of IBS 345 (known as ECCSI) used in this specification is that it requires a 346 trusted Key Management Service (KMS) that issues all private keys, 347 and has complete cryptographic information about all possible private 348 keys. However to set against that, the solution is scalable, as all 349 routers can be independently keyed, and does not need the KMS in the 350 network. If no future keys will be required, then the KMS's master 351 secret can be destroyed. As routers are individually keyed, key 352 revocation (by blacklist and/or time expiry of keys) is possible. 354 ECCSI is based on elliptic curve mathematics. This specification 355 follows [RFC6507] in its recommendation of elliptic curves, but any 356 suitable (prime power) elliptic curve may be used; this must be 357 administratively specified. Implementation of this specification 358 will require an available implementation of suitable mathematical 359 functions. Unlike some other forms of IBS, ECCSI requires only basic 360 elliptic curve operations, it does not require "pairings" (bilinear 361 functions of a product of two elliptic curve groups). This increases 362 the available range of suitable mathematical libraries. 364 6.1. Experimental Status 366 The idea of using identity based signatures for authentication of ad 367 hoc network signaling goes back at least as far as 2005 [Dearlove]. 368 The specific implementation of an identity based signature used in 369 this specification, ECCSI, was published as an Internet Draft in 370 2010, before publication as an informational RFC [RFC6507]. ECCSI is 371 now part of standards such as [ETSI] for LTE Proximity-based 372 Services. An open source implementation of cryptographic software 373 that includes ECCSI is available, see [SecureChorus]. 375 However, although this specification has been implemented for use in 376 an OLSRv2 [RFC7181] routed network, there are only limited reports of 377 such use. There are also no reports of the use of ECCSI within the 378 IETF, other than in this specification. There are no reports of 379 independent public scrutiny of the algorithm, although ECCSI is 380 reported [RFC6507] as being based on [ECDSA] with similar properties. 382 This specification is thus published as experimental, in order to 383 encourage its use and reports on its use. Once experiments have been 384 carried out and reported, and when some public analysis of the 385 underlying cryptographic algorithms is available, it is intended to 386 advance this specification, with any changes identified by such 387 experimentation and analysis, to standards track. 389 7. Acknowledgments 391 The author would like to thank his colleagues who have been involved 392 in identity-based security for ad hoc networks, including (in 393 alphabetical order) Alan Cullen, Peter Smith and Bill Williams. He 394 would also like to thank Benjamin Smith (INRIA/Ecole Polytechnique) 395 for independently recreating the signature and other values in 396 Appendix A to ensure their correctness, and Thomas Clausen (Ecole 397 Polytechnique) for additional comments. 399 8. References 400 8.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 406 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 407 Format", RFC 5444, February 2009. 409 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 410 Signatures for Identity-Based Encryption (ECCSI)", 411 RFC 6507, February 2012. 413 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 414 Check Value and Timestamp TLV Definitions for Mobile Ad 415 Hoc Networks (MANETs)", RFC 7182, April 2014. 417 8.2. Informative References 419 [Dearlove] 420 Dearlove, C., "OLSR Developments and Extensions", 2nd OLSR 421 Interop and Workshop, Ecole Polytechnique, Palaiseau, 422 France, July 2005. 424 [ECDSA] ANSI, "Public Key Cryptography for the Financial Services 425 Industry: The Elliptic Curve Digital Signature Algorithm 426 (ECDSA)", ANSI X9.62-2005, November 2005. 428 [ETSI] ETSI/3GPP, "Universal Mobile Telecommunications System 429 (UMTS); LTE; Proximity-based Services (ProSe); Security 430 aspects", ETSI TS 133 303 V13.2.0 (2016-01), January 2016. 432 [NIST-FIPS-186-4] 433 National Institute of Standards and Technology, "Digital 434 Signature Standard (DSS)", FIPS 186-4, July 2013. 436 [NIST-SP-800-57] 437 National Institute of Standards and Technology, 438 "Recommendation for Key Management - Part 1: General 439 (Revision 3)", SP 800-57, Part 1, Revision 3, July 2012. 441 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 442 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 443 March 2009. 445 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 446 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 447 RFC 6130, April 2011. 449 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 450 "The Optimized Link State Routing Protocol Version 2", 451 RFC 7181, April 2014. 453 [SecureChorus] 454 "Secure Chorus", . 456 Appendix A. Example 458 Appendix C of [RFC6130] contains this example of a HELLO message. 459 (Note that normally, a TIMESTAMP ICV would also be added before the 460 ICV TLV, but for simplicity that step has been omitted here.) 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | HELLO | MF=7 | MAL=3 | Message Length = 45 | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Hop Limit = 1 | Hop Count = 0 | Message Sequence Number | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Head Len = 3 | Head | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Mid 0 | Mid 1 | Mid 2 | Mid 3 | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Mid 4 | Address TLV Block Length = 14 | LOCAL_IF | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Value Len = 4 | HEARD | HEARD | SYMMETRIC | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | LOST | 488 +-+-+-+-+-+-+-+-+ 490 In order to provide an example of an ECCSI ICV Message TLV that may 491 be added to this message, the fields shown need to all have numerical 492 values, both by inserting defined numerical values (e.g., 0 for 493 HELLO) and by selecting example values where needed. The latter 494 consists of: 496 o The message sequence number will be zero. 498 o The five addresses will be 192.0.2.1 to 192.0.2.5. 500 o The message validity time will be 6 seconds, and the message 501 interval time will be 2 seconds, each encoded with a constant 502 value C = 1/1024 seconds, as described in [RFC5497], as referenced 503 from [RFC6130]. 505 In addition, when calculating an ICV, the hop count and hop limit are 506 both set to zero. This results in the message: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |0 0 0 0 0 0 0 0|0 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 0 1 0 1 1 0 1| 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 |0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0|0 0 0 0 0 0 0 1|0 0 0 1 0 0 0 0| 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 |0 0 0 0 0 0 0 1|0 1 1 0 0 1 0 0|0 0 0 0 0 0 0 0|0 0 0 1 0 0 0 0| 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 |0 0 0 0 0 0 0 1|0 1 0 1 1 0 0 0|0 0 0 0 0 1 0 1|1 0 0 0 0 0 0 0| 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 |0 0 0 0 0 0 1 1|1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0| 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 |0 0 0 0 0 0 0 1|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 1|0 0 0 0 0 1 0 0| 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 |0 0 0 0 0 1 0 1|0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0|0 0 0 0 0 0 1 0| 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 |0 1 0 1 0 0 0 0|0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 0 0 0| 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 |0 0 0 0 0 0 1 1|0 0 1 1 0 1 0 0|0 0 0 0 0 0 0 1|0 0 0 0 0 1 0 0| 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 |0 0 0 0 0 1 0 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |0 0 0 0 0 0 0 0| 534 +-+-+-+-+-+-+-+-+ 536 Or in hexadecimal form 538 M := 0x 0073002D 00000000 00080110 01640010 539 01580580 03C00002 01020304 05000E02 540 50000100 03340104 04020201 00 542 The ICV TLV that will be added will have cryptographic function 543 ECCSI-ADDR, and hash function SHA-256. This message has no 544 originator address, but it travels a single hop, and its IP source 545 address can be used. This will be assumed to be 192.0.2.0, with an 546 empty , thus the sender's identity will be, in hexadecimal 547 form: 549 ID := 0x C0000200 551 Parameters for [RFC6507] will thus be n = 256, N = 32. The same 552 parameters and master key will be used as in Appendix A of [RFC6507], 553 i.e., the elliptic curve P-256, with parameters: 555 p := 0x FFFFFFFF 00000001 00000000 00000000 556 00000000 FFFFFFFF FFFFFFFF FFFFFFFF 558 B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 559 651D06B0 CC53B0F6 3BCE3C3E 27D2604B 561 q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 562 BCE6FAAD A7179E84 F3B9CAC2 FC632551 564 G := 0x 04 565 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 566 77037D81 2DEB33A0 F4A13945 D898C296 567 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 568 2BCE3357 6B315ECE CBB64068 37BF51F5 570 KSAK := 0x 12345; 572 KPAK := 0x 04 573 50D4670B DE75244F 28D2838A 0D25558A 574 7A72686D 4522D4C8 273FB644 2AEBFA93 575 DBDD3755 1AFD263B 5DFD617F 3960C65A 576 8C298850 FF99F203 66DCE7D4 367217F4 578 The remaining steps to creating a private key for ID use the same 579 "random" value v as Appendix A of [RFC6507] and are: 581 v := 0x 23456 583 PVT := 0x 04 584 758A1427 79BE89E8 29E71984 CB40EF75 585 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 586 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 587 A464AE49 34663C52 65BA7018 BA091F79 589 HS := hash( 0x 04 590 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 591 77037D81 2DEB33A0 F4A13945 D898C296 592 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 593 2BCE3357 6B315ECE CBB64068 37BF51F5 594 04 595 50D4670B DE75244F 28D2838A 0D25558A 596 7A72686D 4522D4C8 273FB644 2AEBFA93 597 DBDD3755 1AFD263B 5DFD617F 3960C65A 598 8C298850 FF99F203 66DCE7D4 367217F4 599 C0000200 600 04 601 758A1427 79BE89E8 29E71984 CB40EF75 602 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 603 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 604 A464AE49 34663C52 65BA7018 BA091F79 ) 606 = 0x F64FFD76 D2EC3E87 BA670866 C0832B80 607 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 609 The remaining steps to creating a signature for M use the same 610 "random" value j as Appendix A of [RFC6507] and are: 612 j := 0x 34567 614 J := 0x 04 615 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 616 DFE6029C 2AFFC493 6008CD2C C1045D81 617 6DDA6A13 10F4B067 BD5DABDA D741B7CE 618 F36457E1 96B1BFA9 7FD5F8FB B3926ADB 620 r := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 621 DFE6029C 2AFFC493 6008CD2C C1045D81 623 HE := hash( 0x 624 F64FFD76 D2EC3E87 BA670866 C0832B80 625 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 626 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 627 DFE6029C 2AFFC493 6008CD2C C1045D81 628 0073002D 00000000 00080110 01640010 629 01580580 03C00002 01020304 05000E02 630 50000100 03340104 04020201 00 ) 632 = 0x FE236B30 CF72E060 28E229ED 5751D796 633 91DED33C 24D2F661 28EA0804 30D8A832 635 s' := 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 636 2E2669CF 209EA622 7D7072BA A83C2509 638 s := 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 639 2E2669CF 209EA622 7D7072BA A83C2509 641 Signature := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 642 DFE6029C 2AFFC493 6008CD2C C1045D81 643 C8C739D5 FB3EFB75 221CB818 8CAAB86A 644 2E2669CF 209EA622 7D7072BA A83C2509 645 04 646 758A1427 79BE89E8 29E71984 CB40EF75 647 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 648 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 649 A464AE49 34663C52 65BA7018 BA091F79 651 Author's Address 653 Christopher Dearlove 654 BAE Systems Applied Intelligence Laboratories 655 West Hanningfield Road 656 Great Baddow, Chelmsford 657 United Kingdom 659 Phone: +44 1245 242194 660 Email: chris.dearlove@baesystems.com 661 URI: http://www.baesystems.com/