idnits 2.17.1 draft-ietf-manet-ibs-01.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 ([RFC7182], [RFC5444], [RFC6507]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- 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? -- The draft header indicates that this document updates RFC7182, but the abstract doesn't seem to directly say this. It does mention RFC7182 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 24, 2014) is 3535 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) ** Downref: Normative reference to an Informational RFC: RFC 6507 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 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 ATC 4 Updates: 7182 (if approved) July 24, 2014 5 Intended status: Standards Track 6 Expires: January 25, 2015 8 Identity-Based Signatures for MANET Routing Protocols 9 draft-ietf-manet-ibs-01 11 Abstract 13 This document extends [RFC7182], which specifies a framework for, and 14 specific examples of, integrity check values (ICVs) for packets and 15 messages using the generalized packet/message format specified in 16 [RFC5444]. It does so by defining an additional cryptographic 17 function that allows the creation of an ICV that is an identity-based 18 signature, defined according to the ECCSI (Elliptic Curve-Based 19 Certificateless Signatures for Identity-Based Encryption) algorithm 20 specified in [RFC6507]. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 25, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 59 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Cryptographic Function . . . . . . . . . . . . . . . . . . 5 61 4.2. ECCSI parameters . . . . . . . . . . . . . . . . . . . . . 6 62 4.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 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 that 78 allow the use of an identity-based signature (IBS) as an ICV. An IBS 79 has an additional property that is not shared by any of the 80 previously specified ICVs, it not only indicates that the protected 81 packet or message is valid, but also verifies the originator of the 82 packet/message. 84 This specification assumes that each router (protocol participant) 85 has an identity that may be tied to the packet or message. The 86 router may have more than one identity, but will only use one for 87 each ICV TLV. The cryptographic strength of the IBS is not dependent 88 on the choice of identity. 90 Two options for the choice of identity are supported (the two code 91 points allocated). In the first the identity can be any octet 92 sequence (up to 255 octets) included in the ICV TLV. In the second, 93 the octet sequence is preceded by an address, either the IP source 94 address for a packet TLV, or the message originator address for a 95 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, compared to the shared secret key ICVs 99 specified in [RFC7182], allow identifying the originator of 100 information in a packet or message. They thus allow additional 101 security functions, such as revocation of an identity, and removing 102 all information with a specific originator, if this is recorded - as 103 it is for OLSRv2 [RFC7181], an expected user of this specification. 104 When applied to messages (rather than packets) this can significantly 105 reduce the damage that a compromised router can inflict on the 106 network. 108 Identity-based signatures are based on forms of asymmetric (public 109 key) cryptography - identity-based encryption (IBE). In terms of 110 their use, IBE and IBS methods have a major advantage, and a major 111 disadvantage, compared to more widely used public key cryptography 112 solutions, such as RSA. 114 The advantage referred to is that each router can be configured once 115 (for its key lifetime) by a trusted authority, independently of all 116 other routers. Thus router A can connect to the authority (typically 117 in a secure environment) to receive a private key, or can have a 118 private key delivered securely (out of band) from the authority. 119 During normal operation of the MANET, there is no need for the 120 trusted authority to be connected to the MANET, or even to still 121 exist. Additional routers can be authorized, with no reference to 122 previously authorized routers (the trusted authority must still exist 123 in this case). A router's public key is its identity, which when 124 tied to a packet or message (as is the case when using an address as, 125 or as part of, the identity) means that there is no need for public 126 key certificates or a certificate authority. 128 The disadvantage referred to is that the trusted authority has 129 complete authority, even more so than a conventional certificate 130 authority. Routers cannot generate their own private keys, only the 131 trusted authority can do that. Through the master secret held by the 132 trusted authority, it could impersonate any router (existing or not). 133 When used for identity-based encryption (not part of this 134 specification) the trusted authority can decrypt anything. However, 135 note that the shared secret key options described in [RFC7182] also 136 have this limitation. 138 There are alternative mathematical realizations of identity-based 139 signatures. This specification uses one that has been previously 140 published as [RFC6507], known as ECCSI (Elliptic Curve-Based 141 Certificateless Signatures for Identity-Based Encryption). In common 142 with other identity-based encryption/signature approaches, it is 143 based on the use of elliptic curves. Unlike some, it does not use 144 "pairings" (bilinear maps from a product of two elliptic curve groups 145 to another group). It thus may be easier to implement, and more 146 efficient, than some alternatives, although with a greater signature 147 size than some. This specification allows the use of any elliptic 148 curve that may be used by [RFC6507]. 150 The computational load imposed by ECCSI (and, perhaps more so, other 151 IBS methods) is not trivial, though depending significantly on the 152 quality of implementation of the required elliptic curve and other 153 mathematical functions. For a security level of 128 bits, the ICV 154 data length is 129 octets, which is longer than for alternative ICVs 155 specified in [RFC7182] (e.g., 32 octets for the similar strength 156 HMAC-SHA-256). The signature format used could have been slightly 157 shortened (to 97 octets) by using a compressed representation of an 158 elliptic curve point, however at the expense of some additional work 159 when verifying a signature, and loss of direct compatibility with 160 [RFC6507], and implementations thereof. 162 The trusted authority is referred to in [RFC6507] as the KMS (Key 163 Management Service). That term will be used in the rest of this 164 specification. 166 2. Terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in 171 [RFC2119]. 173 Additionally, this document uses the terminology of [RFC5444], 174 [RFC6507], and [RFC7182]. 176 3. Applicability Statement 178 This specification adds an additional option to the framework 179 specified in [RFC7182] for use by [RFC5444] formatted packets and 180 messages. It is applicable as described in [RFC7182], and subject to 181 the additional comments in Section 6. 183 Specific examples of protocols for which this specification is 184 suitable are NHDP [RFC6130] and OLSRv2 [RFC7181]. 186 4. Specification 188 4.1. Cryptographic Function 190 This specification defines a cryptographic function named ECCSI that 191 is implemented as specified as the "sign" function in Section 5.2.1 192 of [RFC6507]. To use that specification: 194 o The ICV is not calculated as cryptographic-function(hash- 195 function(content)) as defined in [RFC7182], but (like the HMAC 196 ICVs defined there) uses the hash function within the 197 cryptographic function. The option "none" is not permitted for 198 hash-function, and the hash function must have a known fixed 199 length of N octets, as specified in Section 4.2. 201 o M in [RFC6507] is "content" as specified in in [RFC7182]. 203 o ID, used in [RFC6507], is as specified in Section 4.3. 205 o KPAK, SSK and PVT, used in [RFC6507], are as specified in Sections 206 4.2 and 5.1.1 of [RFC6507], provided by the KMS. 208 The length of the signature is 4N+1 octets, as specified in 209 [RFC6507], whose affine coordinate format (including an octet valued 210 0x04 to identify this) is used unchanged. 212 Verification of the ICV is not implemented by the receiver 213 recalculating the ICV and comparing with the received ICV, as it is 214 necessarily incapable of doing so. Instead the receiver evaluates 215 the "verify" function described in Section 5.2.2 of [RFC6507], which 216 may pass or fail. 218 To use that function M, KPAK, SSK and PVT are as specified above, 219 while ID is deduced from the received packet or message, as specified 220 in Section 4.3, using the element in the . This 221 element need not match that used by the receiver, and thus when using 222 this cryptographic function, multiple ICV TLVs differing only in 223 their , or in the choice of cryptographic function from the 224 two defined in this specification, SHOULD NOT be used unless routers 225 are administratively configured to recognize which to verify. 227 Routers MAY be administratively configured to reject a packet or 228 message ICV TLV using ECCSI based on part or all of ; for 229 example if this encodes a time after which this identity is no longer 230 valid. 232 4.2. ECCSI parameters 234 Section 4.1 of [RFC6507] specifies parameters n, N, p, E, B, G, and 235 q. The first of these, n, is specified as "A security parameter; the 236 size in bits of the prime p over which elliptic curve cryptography is 237 to be performed." For typical security levels (e.g., 128, 192 and 238 256 bits), n must be at least twice the required bits of security, 239 see Section 5.6.1 of [NIST-SP-800-57]. 241 Selection of an elliptic curve, and all related parameters, MUST be 242 by administrative means, and known to all routers. This 243 specification follows [RFC6507] with a RECOMMENDED selection to 244 follow Appendix D.1.2 of [NIST-FIPS-186-4]. (Note that n in that 245 document is q in [RFC6507].) 247 The parameter that is required by this specification is N, which is 248 defined as Ceiling(n/8). The hash function used must create an 249 output of size N octets. In particular for 128 bit security, and 250 hence n = 256, N = 32, and the RECOMMENDED hash function is SHA-256. 251 The signature (i.e. ) length is 4N + 1 octets, i.e., 129 252 octets for N = 32. 254 Note: [RFC6507] actually refers to the predecessor to 255 [NIST-FIPS-186-4], but the latest version is specified here; there 256 are no significant differences in this regard. 258 4.3. Identity 260 There are two options for the identity ID used by [RFC6507], which 261 are indicated by there being two code points allocated for this 262 cryptographic function, see Section 5. 264 o For the cryptographic function ECCSI ID is the element 265 defined in Section 12.1 of [RFC7182]. This MUST NOT be empty. 267 o For the cryptographic function ECCSI-ADDR, ID is the concatenation 268 of an address (in network byte order) and the element 269 defined in Section 12.1 of [RFC7182], where the latter MAY be 270 empty. For a packet TLV this address is the IP source address of 271 the IP datagram in which this packet is included. For a message 272 TLV or an address block TLV this address is the message originator 273 address (the element defined in [RFC5444]) if that 274 address is present, if not present and the message is known to 275 have travelled only one hop, then the IP source address of the IP 276 datagram in which this message is included is used, otherwise no 277 address is defined and the message MUST be rejected. (Note that 278 HELLO messages specified in NHDP [RFC6130] and used in OLSRv2 279 [RFC7181] always only travel one hop, and hence their IP source 280 address SHOULD be used if no originator address is present.) 282 Note that this identity is formatted by [RFC6507], and thus does not 283 need a length field incorporated into it by this specification. 285 5. IANA Considerations 287 IANA has, in accordance with [RFC7182], defined a registry for the 288 cryptographic functions. IANA is requested to modify this allocation 289 as indicated. 291 +-------+------------+------------------------------+---------------+ 292 | Value | Algorithm | Description | Reference | 293 +-------+------------+------------------------------+---------------+ 294 | 7 | ECCSI | ECCSI [RFC6507] | This | 295 | | | | specification | 296 | 8 | ECCSI-ADDR | ECCSI [RFC6507] with an | This | 297 | | | address (source or | specification | 298 | | | originator) joined to | | 299 | | | identity | | 300 | 9-251 | | Unassigned; Expert Review | | 301 +-------+------------+------------------------------+---------------+ 303 Table 1: Cryptographic Function Registry 305 6. Security Considerations 307 This specification extends the security framework for MANET routing 308 protocols specified in [RFC7182] by the addition of an additional 309 cryptographic function, in two forms according to how identity is 310 specified. 312 This cryptographic function implements a form of identity-based 313 signature (IBS), a stronger form of integrity check value (ICV) that 314 verifies not just that the received packet or message is valid but 315 that the packet or message originated at a router that was assigned a 316 private key for the specified identity. 318 For a message the identity is, and for a packet it is recommended 319 that it is, either the originator address of the router (i.e., an 320 address unique to that router), or the originator address with 321 additional information appended. The use of that additional 322 information is outside the scope of this specification, a typical use 323 may be to indicate an expiry time for signatures created using that 324 identity. 326 In common with other forms of IBS, a feature of the form of IBS 327 (known as ECCSI) used in this specification is that it requires a 328 trusted authority (KMS) that issues all private keys, and has 329 complete cryptographic information about all possible private keys. 330 However to set against that, the solution is scalable, as all routers 331 can be independently keyed, and does not need the KMS in the network. 332 If no future keys will be required, then the KMS's master secret can 333 be destroyed. As routers are individually keyed, key revocation (by 334 blacklist and time expiry of keys) is possible, but is beyond the 335 scope of this specification. 337 ECCSI is based on elliptic curve mathematics. This specification 338 follows [RFC6507] in its recommendation of elliptic curves, but any 339 suitable (prime power) elliptic curve may be used; this must be 340 administratively specified. Implementation of this specification 341 will require an available implementation of suitable mathematical 342 functions. Unlike some other forms of IBS, ECCSI requires only basic 343 elliptic curve operations, it does not require "pairings" (bilinear 344 functions of a product of two elliptic curve groups). This increases 345 the available range of suitable mathematical libraries. 347 7. Acknowledgments 349 The author would like to thank his colleagues who have been involved 350 in identity-based security for ad hoc networks, including (in 351 alphabetical order) Alan Cullen, Peter Smith and Bill Williams. He 352 would also like to thank Benjamin Smith (INRIA/Ecole Polytechnique) 353 for independently recreating the signature and other values in 354 Appendix A to ensure their correctness. 356 8. References 358 8.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, 364 "Generalized Mobile Ad Hoc Network (MANET) Packet/Message 365 Format", RFC 5444, February 2009. 367 [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless 368 Signatures for Identity-Based Encryption (ECCSI)", 369 RFC 6507, February 2012. 371 [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity 372 Check Value and Timestamp TLV Definitions for Mobile Ad 373 Hoc Networks (MANETs)", RFC 7182, April 2014. 375 8.2. Informative References 377 [NIST-FIPS-186-4] 378 National Institute of Standards and Technology, "Digital 379 Signature Standard (DSS)", FIPS 186-4, July 2013. 381 [NIST-SP-800-57] 382 National Institute of Standards and Technology, 383 "Recommendation for Key Management - Part 1: General 384 (Revision 3)", SP 800-57, Part 1, Revision 3, July 2012. 386 [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value 387 Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, 388 March 2009. 390 [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc 391 Network (MANET) Neighborhood Discovery Protocol (NHDP)", 392 RFC 6130, April 2011. 394 [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 395 "The Optimized Link State Routing Protocol Version 2", 396 RFC 7181, April 2014. 398 Appendix A. Example 400 Appendix C of [RFC6130] contains this example of a HELLO message. 401 (Note that normally, a TIMESTAMP ICV would also be added before the 402 ICV TLV, but for simplicity that step has been omitted here.) 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | HELLO | MF=7 | MAL=3 | Message Length = 45 | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Hop Limit = 1 | Hop Count = 0 | Message Sequence Number | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Message TLV Block Length = 8 | VALIDITY_TIME | MTLVF = 16 | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Value Len = 1 | Value (Time) | INTERVAL_TIME | MTLVF = 16 | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Value Len = 1 | Value (Time) | Num Addrs = 5 | ABF = 128 | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Head Len = 3 | Head | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Mid 0 | Mid 1 | Mid 2 | Mid 3 | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Mid 4 | Address TLV Block Length = 14 | LOCAL_IF | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | ATLVF = 80 | Index = 0 | Value Len = 1 | THIS_IF | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | LINK_STATUS | ATLV = 52 | Strt Indx = 1 | Stop Indx = 4 | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Value Len = 4 | HEARD | HEARD | SYMMETRIC | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | LOST | 430 +-+-+-+-+-+-+-+-+ 432 In order to provide an example of an ECCSI ICV Message TLV that may 433 be added to this message, the fields shown need to all have numerical 434 values, both by inserting defined numerical values (e.g. 0 for HELLO) 435 and by selecting example values where needed. The latter consists 436 of: 438 o The message sequence number will be zero. 440 o The five addresses will be 192.0.2.1 to 192.0.2.5. 442 o The message validity time will be 6 seconds, and the message 443 interval time will be 2 seconds, each encoded with a constant 444 value C = 1/1024 seconds, as described in [RFC5497], as referenced 445 from [RFC6130]. 447 In addition, when calculating an ICV, the hop count and hop limit are 448 both set to zero. This results in the message: 450 0 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |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| 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |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| 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 |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| 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 |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| 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 |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| 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 |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| 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 |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| 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |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| 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |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| 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 |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| 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 |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| 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 |0 0 0 0 0 0 0 0| 476 +-+-+-+-+-+-+-+-+ 478 Or in hexadecimal form 480 M := 0x 0073002D 00000000 00080110 01640010 481 01580580 03C00002 01020304 05000E02 482 50000100 03340104 04020201 00 484 The ICV TLV that will be added will have cryptographic function 485 ECCSI-ADDR, and hash function SHA-256. This message has no 486 originator address, but it travels a single hop, and its IP source 487 address can be used. This will be assumed to be 192.0.2.0, with an 488 empty , thus the sender's identity will be, in hexadecimal 489 form: 491 ID := 0x C0000200 493 Parameters for [RFC6507] will thus be n = 256, N = 32. The same 494 parameters and master key will be used as in Appendix A of [RFC6507], 495 i.e., the elliptic curve P-256, with parameters: 497 p := 0x FFFFFFFF 00000001 00000000 00000000 498 00000000 FFFFFFFF FFFFFFFF FFFFFFFF 500 B := 0x 5AC635D8 AA3A93E7 B3EBBD55 769886BC 501 651D06B0 CC53B0F6 3BCE3C3E 27D2604B 503 q := 0x FFFFFFFF 00000000 FFFFFFFF FFFFFFFF 504 BCE6FAAD A7179E84 F3B9CAC2 FC632551 506 G := 0x 04 507 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 508 77037D81 2DEB33A0 F4A13945 D898C296 509 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 510 2BCE3357 6B315ECE CBB64068 37BF51F5 512 KSAK := 0x 12345; 514 KPAK := 0x 04 515 50D4670B DE75244F 28D2838A 0D25558A 516 7A72686D 4522D4C8 273FB644 2AEBFA93 517 DBDD3755 1AFD263B 5DFD617F 3960C65A 518 8C298850 FF99F203 66DCE7D4 367217F4 520 The remaining steps to creating a private key for ID use the same 521 "random" value v as Appendix A of [RFC6507] and are: 523 v := 0x 23456 525 PVT := 0x 04 526 758A1427 79BE89E8 29E71984 CB40EF75 527 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 528 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 529 A464AE49 34663C52 65BA7018 BA091F79 531 HS := hash( 0x 04 532 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 533 77037D81 2DEB33A0 F4A13945 D898C296 534 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 535 2BCE3357 6B315ECE CBB64068 37BF51F5 536 04 537 50D4670B DE75244F 28D2838A 0D25558A 538 7A72686D 4522D4C8 273FB644 2AEBFA93 539 DBDD3755 1AFD263B 5DFD617F 3960C65A 540 8C298850 FF99F203 66DCE7D4 367217F4 541 C0000200 542 04 543 758A1427 79BE89E8 29E71984 CB40EF75 544 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 545 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 546 A464AE49 34663C52 65BA7018 BA091F79 ) 548 = 0x F64FFD76 D2EC3E87 BA670866 C0832B80 549 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 551 The remaining steps to creating a signature for M use the same 552 "random" value j as Appendix A of [RFC6507] and are: 554 j := 0x 34567 556 J := 0x 04 557 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 558 DFE6029C 2AFFC493 6008CD2C C1045D81 559 6DDA6A13 10F4B067 BD5DABDA D741B7CE 560 F36457E1 96B1BFA9 7FD5F8FB B3926ADB 562 r := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 563 DFE6029C 2AFFC493 6008CD2C C1045D81 565 HE := hash( 0x 566 F64FFD76 D2EC3E87 BA670866 C0832B80 567 B740C2BA 016034C8 1A6F5E5B 5F9AD8F3 568 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 569 DFE6029C 2AFFC493 6008CD2C C1045D81 570 0073002D 00000000 00080110 01640010 571 01580580 03C00002 01020304 05000E02 572 50000100 03340104 04020201 00 ) 574 = 0x FE236B30 CF72E060 28E229ED 5751D796 575 91DED33C 24D2F661 28EA0804 30D8A832 577 s' := 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 578 2E2669CF 209EA622 7D7072BA A83C2509 580 s := 0x C8C739D5 FB3EFB75 221CB818 8CAAB86A 581 2E2669CF 209EA622 7D7072BA A83C2509 583 Signature := 0x 269D4C8F DEB66A74 E4EF8C0D 5DCC597D 584 DFE6029C 2AFFC493 6008CD2C C1045D81 585 C8C739D5 FB3EFB75 221CB818 8CAAB86A 586 2E2669CF 209EA622 7D7072BA A83C2509 587 04 588 758A1427 79BE89E8 29E71984 CB40EF75 589 8CC4AD77 5FC5B9A3 E1C8ED52 F6FA36D9 590 A79D2476 92F4EDA3 A6BDAB77 D6AA6474 591 A464AE49 34663C52 65BA7018 BA091F79 593 Author's Address 595 Christopher Dearlove 596 BAE Systems Advanced Technology Centre 597 West Hanningfield Road 598 Great Baddow, Chelmsford 599 United Kingdom 601 Phone: +44 1245 242194 602 Email: chris.dearlove@baesystems.com 603 URI: http://www.baesystems.com/