idnits 2.17.1 draft-kempf-secure-nd-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2002) is 8105 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) == Unused Reference: '5' is defined on line 708, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) -- No information found for draft-kempf-netaccess-threats - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 2373 (ref. '3') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2402 (ref. '4') (Obsoleted by RFC 4302, RFC 4305) == Outdated reference: A later version (-28) exists of draft-ietf-dhc-dhcpv6-23 -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-03) exists of draft-montenegro-sucv-02 -- Possible downref: Normative reference to a draft: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' -- Possible downref: Non-RFC (?) normative reference: ref. '21' -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Downref: Normative reference to an Informational RFC: RFC 2881 (ref. '24') ** Obsolete normative reference: RFC 2486 (ref. '25') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2462 (ref. '26') (Obsoleted by RFC 4862) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 James Kempf 3 Internet Draft Craig Gentry 4 Document: draft-kempf-secure-nd-00.txt Alice 5 Silverberg 6 Expires: August 2002 February 2002 8 Securing IPv6 Neighbor Discovery Using Address Based Keys (ABKs) 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 When an IPv6 host receives a Router Advertisement, how does it know 33 that the node which sent the advertisement is authorized to route 34 the advertised prefix? When an IPv6 node receives a Neighbor 35 Advertisement message, how does it know that the node sending the 36 message is, in fact, the one for which the address binding applies? 37 The answer is, in the absence of a preconfigured IPSec security 38 association among the nodes on the link and the router, they don't. 39 In this draft, a lightweight protocol is described for securing the 40 signaling involved in IPv6 Neighbor Discovery. The protocol allows a 41 node receiving a Router Advertisement or a Neighbor Advertisement to 42 have the confidence that the message was sent by the legitimate 43 owner of the address or prefix being advertised without requiring a 44 preconfigured IPSec security association. A certain degree of 45 infrastructural support is required, but not any more than is 46 currently common for public access IP networks. The protocol is 47 based on some results in identity based cryptosystems that allow a 48 publicly known identifier to function as a public key. 50 Contents 51 1.0 Introduction...................................................2 52 2.0 Terminology....................................................3 53 3.0 What are Identity Based Cryptosystems?.........................4 54 4.0 Digital Signature Calculations.................................5 55 5.0 Host and Router Configuration..................................5 56 5.1 Router Configuration........................................5 57 5.2 Host Configuration..........................................6 58 6.0 Securing Router Advertisement..................................6 59 6.1 Router Advertisement Signature..............................7 60 6.2 Verifying a Router Advertisement............................7 61 6.3 Negotiating an Identity based Algorithm.....................8 62 7.0 Securing Neighbor Discovery..................................8 63 7.1 Neighbor Advertisement Signature............................8 64 7.2 Verifying a Neighbor Advertisement..........................9 65 7.3 Negotiating an Identity Based Algorithm.....................9 66 8.0 Option Formats...............................................9 67 8.1 Identity Digital Signature Option...........................9 68 8.2 Identity Algorithm Option..................................10 69 9.0 Identity Based Key Algorithms...............................11 70 10.0 Previous Work..............................................12 71 11.0 Infrastructure Requirements................................13 72 12.0 Security Considerations....................................14 73 13.0 References.................................................14 74 14.0 Author's Contact Information...............................15 75 15.0 Full Copyright Statement...................................16 76 16.0 IPR Statement..............................................16 78 1.0 Introduction 80 The IPv6 Neighbor Discovery protocol described in RFC 2461 [1] plays 81 a critical role in last hop network access for IPv6 nodes. The 82 protocol allows a IP host joining a link to discover a router, and 83 for nodes on the link, including the router, to discover the link 84 layer address of an IP node on the link to which IP traffic must be 85 delivered. Disruption of this protocol can have a serious impact on 86 the ability of nodes to send and receive IP traffic. 88 Yet, security on the protocol is weak. As stated in the Security 89 Considerations section of RFC 2461: 91 The protocol contains no mechanism to determine which 92 neighbors are authorized to send a particular type of 93 message...; any neighbor, presumably even in the presence of 94 authentication, can send Router Advertisement messages thereby 95 being able to cause denial of service. Furthermore, any 96 neighbor can send proxy Neighbor Advertisements as well as 97 unsolicited Neighbor Advertisements as a potential denial of 98 service attack. 100 In [2], a list of threats to IPv6 Neighbor Discovery on multi-access 101 links is outlined. These threats can occur for both wired and 102 wireless public multi-access links. They are a particular problem 103 for wireless links, however, because even private multi-access links 104 over shared access (as opposed to switched) media with link level 105 authentication mechanisms such as 802.1x [22] are subject to 106 disruption if an authenticated host decides to play the trickster. 108 RFC 2461 recommends using IPSec AH authentication [4] if a security 109 association exists, but this is a fairly heavyweight solution and is 110 unlikely to be widely applicable to public access networks. In 111 particular, a roaming host in a foreign public access network is 112 unlikely to have a security association with the local access router 113 or with other hosts on the same link. Indeed, most of the nodes on 114 the same link may not even have the same home ISP as the roaming 115 node. 117 In this document, a lightweight protocol that secures IPv6 Neighbor 118 Discovery is described. The protocol allows IP hosts to verify that 119 a node advertising routing for a local subnet prefix is allowed to 120 route the prefix, and that information provided in a Neighbor 121 Discovery message is authentically from the sending host. A certain 122 amount of infrastructure is required, but no more than is currently 123 needed for public access IP networks. In particular, no extension of 124 the current NAS-based AAA infrastructure [24] nor a global PKI are 125 necessary. The protocol depends on some results in identity based 126 cryptosystems whereby a publicly known identifier, in this case, 127 parts of a node's IP address, can serve as a public key. The 128 technique whereby addresses are used to generate public/private key 129 pairs is called Address Based Keys (ABKs). 131 2.0 Terminology 133 Address Based Keys (ABKs) - A technique whereby an identity 134 based cryptosystem is used to generate a node's public and 135 private key from its IPv6 subnet prefix or interface 136 identifier. 138 Identity based cryptosystem - A cryptographic technique that 139 allows a publicly known identifier, such as the IPv6 address, 140 to be used as a public key for authentication, key agreement, 141 and encryption. 143 Identity based Private Key Generator (IPKG) - An agent that is 144 capable of executing an identity based cryptographic algorithm 145 to generate a private key when presented with the public 146 identifier that will act as the public key. 148 Public cryptographic parameters - A collection of publicly 149 known parameters formed from chosen constants and the secret 150 key known only to the IPKG, specific to the identity based 151 cryptographic algorithm, which the IPKG uses to generate the 152 node's private key and which two nodes involved in securing or 153 encrypting a message use to perform cryptographic operations. 155 Network Access Server (NAS) - A server that performs 156 Authentication, Authorization, and Accounting (AAA) for hosts 157 in a public access network. 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 161 document are to be interpreted as described in [23]. 163 3.0 What are Identity Based Cryptosystems? 165 Identity based cryptosystems are a collection of cryptographic 166 techniques that allow a publicly known identifier, such as the email 167 address or (particularly important in this application) the IP 168 address of a node, to function as the public key part of a 169 public/private key pair for purposes of digital signature 170 calculation, key agreement, and encryption. Section 9.0 provides a 171 quick overview of the available algorithms, with an extensive 172 reference list. While identity based cryptosystems have been 173 investigated for almost 20 years in the cryptographic community, 174 they have not been widely discussed in the network security 175 community. The reason is unclear, but it might have to do with the 176 popularity and algorithmic simplicity of the reigning standard 177 Diffie-Hellman technique, or possibly to the fact that, until 178 recently, there have been no known identity based cryptographic 179 algorithms that can be used to perform encryption. The existing 180 algorithms have been restricted to digital signature calculation, 181 and therefore have been fairly limited in scope. Hopefully, should 182 identity based cryptosystems prove useful to the network security 183 community, increased communication between the cryptography and 184 network security communities will lead to a refinement of the 185 algorithms and applications of identity based algorithms for 186 application to securing IPv6 signaling. 188 Elliptic curve (EC) algorithms are particularly attractive for 189 identity based keys because they work well with small key sizes, are 190 computationally efficient on small hosts, such as small wireless 191 devices, and may generate smaller signatures. In addition, while 192 non-EC algorithms have been proposed for identity based digital 193 signature calculation, at the time of this writing, the most 194 efficient way of performing identity based encryption is an EC 195 algorithm. 197 Identity based cryptosystems work in the following way. A publicly 198 known identifier is submitted to an IPKG. In this application, the 199 publicly known identifier is either the 64 bit subnet prefix or the 200 unique 62 bit interface identifier of an IPv6 address. The IPKG uses 201 a particular algorithm to generate the private key and returns it. 202 The public and private key can now be used for authentication and 203 encryption as is typical in cryptosystems. 205 4.0 Digital Signature Calculations 207 Digital signatures MUST be calculated using the following algorithm: 209 sig = SIGN(hash(contents),IPrK,Params) 211 where: 213 sig - The digital signature. 214 SIGN - The identity based digital signature algorithm used 215 to calculate the signature. 216 hash - The HMAC-SHA1 one-way hash algorithm. 217 IPrK - The Identity based Private Key. 218 Params - The public cryptographic parameters. 219 contents - The message contents to be signed. 221 The digital signature MUST be verified using the following 222 algorithm: 224 IPuK = IBC-HASH(ID) 225 valid = VERIFY(hash(contents),sig,IPuK) 227 where: 229 IBC-HASH - A hash function specific to the identity based 230 algorithm that generates the public key from the 231 public identifier. 232 ID - The publicly known identifier used to generate the 233 key. 234 IPuK - The Identity based Public Key. 235 sig - The digital signature. 236 VERIFY - The identity based public key algorithm used to 237 verify the signature. 238 Params - The public cryptographic parameters. 239 valid - 1 if the signature is verified, 0 if not. 241 5.0 Host and Router Configuration 243 Hosts and last hop routers participating in Neighbor Discovery 244 require configuration with the identity based private key and with 245 cryptographic parameters before they can secure messaging. 247 5.1 Router Configuration 249 When the ISP or network owner sets up its last hop routers, the 250 routers are configured with the 64 bit subnet prefix or prefixes 251 that they should advertise. In addition, the ISP uses its IPKG to 252 generate a private key per prefix. The router uses this key in 253 generating digital signatures on Router Advertisements. The private 254 key and the public cryptographic parameters MUST be installed on the 255 router through a secure channel. Examples of possible secure 256 channels include configuration by a network administrator, 257 installation via an NAS-based AAA network capable of secure key 258 distribution, installation via a secure message exchange to a server 259 with which the router has an IPSec security association, etc. 261 5.2 Host Configuration 263 Hosts require an identity based private key associated with their 62 264 bit interface identifier, which is the bottom 62 bits (64 bits minus 265 the "u" and "g" bit, see RFC 2373 [3]) in the IPv6 address, and the 266 public cryptographic parameters. There are two possible ways in 267 which the host can be configured: dynamically, when the host is 268 initially authenticated and authorized for network access through a 269 secure connection with the local network's NAS or statically, when 270 its home ISP initially assigns the interface identifier. 272 Most public access networks currently require a host to undergo a 273 secure authentication and authorization exchange through a NAS prior 274 to being able to use the network. Since this exchange is typically 275 performed at Layer 2 before any IP signaling, it can be done prior 276 to any Neighbor Discovery signaling. The host includes its interface 277 identifier in a message to the NAS. The NAS sends the interface 278 identifier to the IPKG, where the private key is generated. The 279 private key and public cryptographic parameters are then securely 280 transferred back to the host where they are installed. The host uses 281 this private key is just used for securing IPv6 Neighbor Discovery 282 traffic on the foreign network, not for securing any private data, 283 because the key belongs to the foreign network. After router 284 discovery, the host uses the interface id and subnet prefix from the 285 router to construct the router's IP address using IPv6 Stateless 286 Address Autoconfiguration. The hosts on the local link and the last 287 hop router then use the public cryptographic parameters and the 288 private keys given to them by the network to secure IPv6 Neighbor 289 Discovery signaling. 291 Some public access networks may not perform secure Layer 2 292 authentication and authorization prior to allowing the host to 293 perform Neighbor Discovery. In order to accommodate these kinds of 294 networks, hosts MUST be configured with public cryptographic 295 parameters and a private key by their home ISPs or network 296 operators. The messaging for securing Neighbor Discovery includes an 297 identifier based on the realm portion of the NAI [25]. This 298 identifier allows the hosts and routers on the local link to 299 authenticate the signaling of guest hosts. Roaming consortia co- 300 ordinate their IPKGs so that the various ISPs in the consortium can 301 accommodate guest hosts. If the static configuration method is used, 302 the cryptographic parameters for both router and host authentication 303 must be installed, since they need not be identical. 305 6.0 Securing Router Advertisement 307 In this section, a protocol for securing IPv6 router advertisement 308 is discussed. 310 6.1 Router Advertisement Signature 312 A Router Advertisement sent by a router configured with a 64 bit 313 prefix key contains a digital signature. The signature MUST sign all 314 relevant fields within the message, including all ICMP message 315 options, if any. These include: 317 - Current hop limit (chl) 318 - Flags (fl) 319 - Router lifetime (rol) 320 - Reachable lifetime (rel) 321 - Retransmit timer (rtt) 322 - Source link-layer address option (if there) (sllao) 323 - MTU option (if there) (mtuo) 324 - Prefix option (pro) 325 - The Identity Digital Signature option without signature 326 (idso) 327 - Any other options (...) 329 In the signing algorithm described in Section 4.0, the input into 330 the HMAC-SHA1 algorithm is the following: 332 contents = (chl,fl,rol,rel,rtt,sllao,mtuo,pro,dso,...) 334 IPrK in the signing algorithm is the router's 64 bit subnet prefix. 336 The digital signature MUST be included in an Identity Digital 337 Signature option (see Section 8.1) with the signature, algorithm, 338 and realm identifier. An ICMP option is used instead of IPSec AH 339 Error! Reference source not found. because Neighbor Discovery 340 options that are not recognized by a host are ignored, so a host 341 that can't verify the signature but is interested in risking using 342 an unsecured Router Advertisement can simply ignore the option as a 343 consequence of normal Neighbor Discovery processing, as opposed to 344 having the Router Advertisement rejected by IPSec processing. 346 The Router Advertisement MUST contain a single Prefix option with 347 the prefix for which the key was assigned. If the router also routes 348 other prefixes, it MUST advertise them using separate Router 349 Advertisements. If the router supports multiple identity based 350 algorithms, it MAY include multiple Identity Digital Signature 351 options with signatures calculated by the various algorithms, up to 352 the path MTU. 354 6.2 Verifying a Router Advertisement 356 An IPv6 host receiving a Router Advertisement with an Identity 357 Digital Signature Option verifies that the advertising node is 358 authorized to send the advertisement in the following way. If the 359 Router Advertisement does not contain a routing prefix option, or if 360 it contains more than one routing prefix option, the host SHOULD 361 discard the Router Advertisement, unless the host wants to risk 362 using an unsecured Router Advertisement. If the host does not 363 support one of the algorithms used for signing the message, it 364 SHOULD discard the Router Advertisement, unless the host wants to 365 risk using an unsecured Router Advertisement. 367 The host locates the single routing prefix option and extracts the 368 subnet prefix which the sending node claims it is allowed to route. 369 The host then uses the verification algorithm in Section 4.0 to 370 verify the digital signature using the same value for contents as in 371 Section 6.1. In this calculation, ID is the subnet prefix in the 372 Prefix option. The identity based algorithm and router public 373 cryptographic parameters depend on the algorithm and realm 374 identifier in the Identity Digital Signature option. 376 6.3 Negotiating an Identity based Algorithm 378 A lengthy negotiation process for determining which identity based 379 algorithm to use is obviously not in the interest of supporting a 380 lightweight protocol. However, algorithms do change over time, and 381 therefore it is necessary to have some way whereby a host can 382 indicate in a Router Solicitation which algorithms it supports. If 383 the router cannot provide an authenticator for any of the 384 algorithms, it can simply return an unauthenticated Router 385 Advertisement and the host can take its chances. For this purpose, 386 the host uses an Identity Algorithm option (see Section 8.2). 388 For multicast Router Advertisements, the router can include Identity 389 Digital Signature options for each algorithm it supports, up to the 390 path MTU. Alternatively, the host can be required to solicit the 391 Router Advertisement and tell the router what algorithms it supports 392 in an Identity Algorithm option. 394 7.0 Securing Neighbor Discovery 396 A similar procedure is used for securing IPv6 Neighbor Discovery 397 messages. 399 7.1 Neighbor Advertisement Signature 401 A Neighbor Advertisement sent in reply to a Neighbor Discovery 402 message contains a digital signature calculated with the private key 403 generated from the 62 bit interface identifier and the host public 404 cryptographic parameters. The signature MUST be calculated over all 405 relevant fields within the message, including all options, if any. 406 These include: 408 - Flags (flg) 409 - Target Address (addr) 410 - Target Link Layer Address option (l2addr) 411 - The Identity Digital Signature option itself, without 412 signature (idso) 414 The Target Link Layer Address option MUST be included. 416 In the signing algorithm described in Section 4.0, the input into 417 the hash algorithm is the following: 419 contents = (flg,addr,l2addr) 421 IPrK is the interface identifier private key. 423 The digital signature MUST be included in an Identity Digital 424 Signature option (see Section 8.1) with the signature, algorithm, 425 and realm identifier. Again, an ICMP option is used instead of IPSec 426 AH because Neighbor Discovery options that are not recognized by a 427 host are ignored. 429 7.2 Verifying a Neighbor Advertisement 431 An IPv6 host receiving a Neighbor Advertisement with an Identity 432 Digital Signature option verifies that the advertising node is 433 authorized to send the advertisement in the following way. If the 434 receiving host does not support one of the algorithms used for 435 encrypting the signature, it SHOULD discard the Neighbor 436 Advertisement, unless the host wants to risk using an unsecured 437 Neighbor Advertisement. 439 The host uses the verification algorithm in Section 4.0 to verify 440 the digital signature using the same value for contents as in 441 Section 7.1. In this calculation, ID is the sending node's 62 bit 442 interface identifier. The identity based algorithm and host public 443 cryptographic parameters depend on the algorithm and realm 444 identifier in the Identity Digital Signature option. 446 7.3 Negotiating an Identity Based Algorithm 448 A node sending a Neighbor Solicitation message can indicate what 449 algorithms it is capable of accepting by including an Identity 450 Algorithm option in the message. 452 8.0 Option Formats 454 8.1 Identity Digital Signature Option 456 The Identity Digital Signature Option contains a digital signature 457 calculated using address based private key. It is always the last 458 option in the list. The format of this option, after [1], is: 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | Algorithm Identifier | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Realm Identifier | | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 467 | | 468 + + 469 | | 470 + + 471 | Digital Signature (N bits) | 472 + + 473 | | 474 + + 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 where: 480 Type 8 bit identifier for the option type, 481 assigned by IANA. 483 Length 8 bit unsigned integer giving the 484 option length (including type and 485 length fields) in units of 8 octets. 487 Algorithm Identifier 16 bit nonzero algorithm 488 identifier,assigned by IANA, indicating 489 the identity based algorithm used to 490 sign the message. 492 Realm Identifier Either the 16 bit nonzero HMAC-SHA1 493 hash of the realm part of the NAI [25], 494 or zero to indicate that the current 495 network's IPKG and public cryptographic 496 parameters should be used. 498 Digital Signature An N bit field containing the digital 499 signature. The field is zero aligned to 500 the nearest 8 byte boundary. The exact 501 number of bits is depends on the 502 identity based algorithm and use. 504 8.2 Identity Algorithm Option 506 The Identity Algorithm Option allows a host to indicate which 507 identity based keying algorithms it supports for particular realms 508 when requesting a Router Advertisement or Neighbor Advertisement. 509 The Identity Algorithm Option has the following format: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Type | Length | Algorithm Identifier | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Realm Identifier | ... / 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 where: 521 Type 8 bit identifier for the option type, 522 assigned by IANA. 524 Length 8 bit unsigned integer giving the 525 option length (including type and 526 length fields) in units of 8 octets. 528 Algorithm Identifier 16 bit nonzero algorithm 529 identifier,assigned by IANA, indicating 530 the identity based algorithm used to 531 sign the message. 533 Realm Identifier Either the 16 bit nonzero HMAC-SHA1 534 hash of the realm part of the NAI [25], 535 or zero to indicate the current 536 network's algorithm. 538 and the option contains as many algorithm identifier-realm 539 identifier pairs, in order of preference, as the host supports. The 540 option is zero padded to multiples of 8 bytes. The 542 9.0 Identity Based Key Algorithms 544 Shamir [19] introduced the idea of identity based cryptography in 545 1984. Practical, provably secure identity based signature schemes 546 [12], [11], [13] and Key Agreement Protocols [16] soon followed. 547 Practical, provably secure identity based encryption schemes [8], 548 [10] have only very recently been found. 550 In identity based signature protocols, the host signs a message 551 using its private key supplied by its IPKG. The signature is then 552 verified using the host's identity. In identity based key agreement 553 protocols, two parties share a secret. Each party constructs the 554 secret by using its own private key and the other party's public 555 identity. In identity based encryption, the encryptor uses the 556 recipient's public identity to encrypt a message, and the recipient 557 uses its private key to decrypt the ciphertext. 559 As is generally the case with public-key cryptography, the security 560 of the systems is based on the difficulty of solving a hard number 561 theory problem, such as factoring or a discrete log (or Diffie- 562 Hellman) problem. 564 Elliptic curves and associated pairings have solved the problem of 565 how to do identity based encryption [8], and are used to construct 566 identity based signature [18][14][9] and key agreement [18][21] 567 protocols. 569 There are a number of advantages to using identity based systems 570 that are based on elliptic curves and their pairings. One is that 571 there are compatible elliptic curve-based signature, key agreement, 572 and encryption schemes. This means firstly that the same public 573 key/private key pair and public cryptographic parameters can be used 574 to do signatures, key agreement, and encryption. Secondly, these 575 protocols overlap, so that results of computations and pre- 576 computations done for one system can be used in the others. Further, 577 there are usually efficiency advantages in using elliptic curves, 578 over using other public-key methods. Generally, one obtains shorter 579 signatures, shorter ciphertexts, and shorter key lengths for the 580 same security as other systems. Efficiency can be further enhanced 581 by using abelian varieties in place of elliptic curves [20]. 583 There are identity based signature schemes [9] using elliptic curves 584 and pairings that base their security on the difficulty of solving 585 the elliptic curve Diffie-Hellman problem. This is the same 586 classical hard problem on which standard Elliptic Curve Cryptography 587 (ECC) [17][15] is based. Identity based encryption and key agreement 588 schemes using elliptic curves (or abelian varieties) and pairings 589 rely on the difficulty of solving the bilinear Diffie-Hellman 590 problem. 592 Identity based cryptosystems can be constructed with or without key 593 escrow. Protocols with key escrow can be performed in fewer passes 594 than corresponding systems that do not provide for key escrow. 596 Techniques from threshold cryptography allow the master key 597 information to be distributed or shared among a number of IPKGs so 598 that all of them would have to collude for a host's private key to 599 be known to them. Such a scenario would allow for key escrow if 600 necessary, by agreement among all the IPKGs, but guards against 601 knowledge of the private keys by the IPKGs without their mutual 602 agreement. 604 10.0 Previous Work 606 Cryptographically Generated Addresses (CGAs) [6], also called SUCV 607 identifiers [7], are the closest related work in this area. The 608 primary difference between CGAs and ABKs are the following: 610 - CGAs use the hash of the public key as the interface id in 611 the address suffix, whereas ABKs hash the interface id or 612 subnet prefix to form the public key. 613 - CGAs allow the host to generate the public key/private key 614 pair on its own, whereas ABKs require that the host be 615 provided with a private key by the entity that assigns its 616 address. 617 - ABKs require configuration with the public cryptographic 618 parameters because the IPKG uses a master secret to perform 619 the private key generation, and the master secret might 620 expire or be compromised. 622 The consequences of the first point are that CGAs are not 623 cryptographically active and therefore a separate mechanism is 624 required to distribute the public key. This may be as simple as 625 including it as a separate field in the message. In addition, 626 CGAs are not "topologically active" and therefore cannot be used 627 to sign the subnet prefix in routing. 629 The consequences of the second point are that there is less 630 computational load on the host for ABKs, since it only has to 631 perform signature verification, not public key/private key pair 632 generation. However, CGAs can be used in the absence of any 633 infrastructure whereas ABKs require the host or router to be 634 assigned an address-based private key. In particular, an address 635 used for ABK cannot be arbitrarily assigned using DHCP. An 636 address used for ABK can be constructed using IPv6 Stateless 637 Address Autoconfiguration [26] as long as the node performing the 638 Stateless Address Autoconfiguration has an ABK interface id and 639 private key for the suffix 64 bits of the address and no 640 duplicate is detected. Indeed, the same mechanism described here 641 to secure Neighbor Discovery could also be used to secure 642 Stateless Address Autoconfiguration. 644 The consequences of the third point is that hosts and routers 645 must be preconfigured with the private key and public 646 cryptographic parameters for the operations. In principle, this 647 is no different than key distribution in Diffie-Hellman. In this 648 case, either dynamic or static configuration of the private key 649 and public cryptographic parameters is performed. 651 11.0 Infrastructure Requirements 653 As mentioned previously, ABKs require a certain amount of 654 infrastructure to generate the private keys from the subnet 655 prefix and interface ids. This requirement, in and of itself, is 656 a hindrance for ad hoc networking designs that call for hosts to 657 simply autoconfigure their addresses without requiring an ISP or 658 network operator to be involved. As a practical matter, however, 659 networking infrastructure, such as routers, radio access points, 660 and backbone networks, is likely to continue to be costly to 661 maintain and most users would probably rather pay someone else to 662 administer the network for them, or they will be required to have 663 someone administer their network if they use an enterprise 664 network at school or work. Thus, requiring mechanism supported by 665 the ISP or network administrator to be involved in the 666 configuration of the private key for a router or host and public 667 cryptographic parameters. 669 With some identity based algorithms, the IPKG maintains a copy of 670 the private key, the so-called "key escrow" property. 671 Consequently, the address assignor's IPKG knows the private keys 672 for every address, and can potentially snoop authenticated or 673 encrypted traffic. However, the ABK is only being used to secure 674 IPv6 signaling traffic and not sensitive private data. Both the 675 ISP or network operator and the legitimate client/user have an 676 interest in seeing efficient operation of the network. Most users 677 today are happy to trust their ISPs with their credit card 678 number, trusting their ISP to guard their ABK is probably of 679 equal or lesser extent. 681 If a group of ISPs in a roaming consortium choose to support 682 ABKs, they have to co-ordinate in order to share a master key. 683 There are techniques that allow secure generation of ABKs in such 684 circumstances, but in principle ISPs in a roaming consortium must 685 trust each other for billing and settlement, so business 686 procedures and computational mechanisms for guarding privileged 687 information are likely to be in place. A collection of ISPs that 688 share a contract for IPKGs will allow their customers to securely 689 use their networks, others will either get insecure or no 690 service, just as is the case currently with roaming. 692 12.0 Security Considerations 694 This document describes a scheme for securing IPv6 Neighbor 695 Discovery messaging. As such, the entire document is about security. 697 13.0 References 699 [1] Narten, T., Nordmark, E., and Simpson, W., "Neighbor Discovery 700 for IP Version 6 (IPv6)", RFC 2461, December, 1998. 701 [2] Kempf, J., and Nordmark, E., "Threat Analysis for IPv6 Public 702 Multi-Access Links," draft-kempf-netaccess-threats-00.txt, a 703 work in progress. 704 [3] Hinden, R., and Deering,S., " IP Version 6 Addressing 705 Architecture", RFC 2373, July 1998. 706 [4] Kent, S., and Atkinson, R., " IP Authentication Header," RFC 707 2402, November 1998. 708 [5] Droms, R. (ed), " Dynamic Host Configuration Protocol for IPv6 709 (DHCPv6)", draft-ietf-dhc-dhcpv6-23.txt, a work in progress. 710 [6] O'Shea, G., and Roe, M., "Child-proof Authentication for MIPv6 711 (CAM)", ACM Computer Communications Review, April, 2001. 712 [7] Montenegro, G., and Castellucia, C., "SUCV Identifiers and 713 Addresses," draft-montenegro-sucv-02.txt, a work in progress. 714 [8] D. Boneh and M. Franklin, "Identity based encryption from the 715 Weil pairing", Advances in Cryptology --- Crypto 2001, Lecture 716 Notes in Computer Science 2139, (2001), Springer, 213-229, 717 http://www.cs.stanford.edu/~dabo/papers/ibe.pdf 718 [9] J. C. Cha and J. H. Cheon, "An Identity-Based Signature from 719 Gap Diffie-Hellman Problem", Cryptology ePrint Archive: Report 720 2002/018, http://eprint.iacr.org/2002/018/ 721 [10] C. Cocks, "An identity based encryption scheme based on 722 quadratic residues", http://www.cesg.gov.uk/technology/id- 723 pkc/media/ciren. 724 [11] U. Feige, A. Fiat, and A. Shamir, "Zero-knowledge Proofs of 725 Identity", Journal of Cryptology 1, (1988), 77-94. 726 [12] A. Fiat and A. Shamir, "How to prove yourself: Practical 727 solutions to identification and signature problems", Advances 728 in Cryptology --- Crypto '86, Lecture Notes in Computer Science 729 263, 1986), Springer, 186-194. 731 [13] L. C. Guillou and J.-J. Quisquater, "A practical zero-knowledge 732 protocol fitted to security microprocessors minimizing both 733 transmission and memory", Advances in Cryptology --- EUROCRYPT 734 '88, Lecture Notes in Computer Science 330, (1988), Springer, 735 123-128. 736 [14] F. Hess, "Exponent Group Signature Schemes and Efficient 737 Identity Based Signature Schemes Based on Pairings", Cryptology 738 ePrint Archive: Report 2002/012, 739 http://eprint.iacr.org/2002/012/ 740 [15] N. Koblitz, "Elliptic curve cryptosystems", Mathematics of 741 Computation 48 (1987), 203-209. 742 [16] U. Maurer and Y. Yacobi, "Non-interactive public-key 743 cryptography," Advances in Cryptology --- Eurocrypt '92, 744 Lecture Notes in Computer Science 658,(1993), Springer, 458- 745 460. 746 [17] V. S. Miller, "Uses of elliptic curves in cryptography", 747 Advances in Cryptology --- Crypto'85, Lecture Notes in Computer 748 Science 218, (1986), Springer, 417-426. 749 [18] R. Sakai, K. Ohgishi, and M. Kasahara, "Cryptosystems based on 750 pairing", SCIC 2000-C20, Okinawa, Japan, January 2000 751 [19] A. Shamir, "Identity-Based Cryptosystems and Signature 752 Schemes", Advances in Cryptology --- Crypto '84, Lecture Notes 753 in Computer Science 196, (1984), Springer, 47-53. 754 [20] A. Silverberg and K. Rubin, "The best and worst of 755 supersingular abelian varieties in cryptology", Cryptology e- 756 Print Archive: Report 2002/006, 757 http://eprint.iacr.org/2002/006/ 758 [21] N. P. Smart, "An identity Based authenticated key agreement 759 protocol based on the Weil pairing", Cryptology ePrint Archive: 760 Report 2001/111, http://eprint.iacr.org/2001/111/ 761 [22] "802.1x - Port Based Access Control", IEEE Standard for Local 762 and Metropolitan Area Networks, 2001. 763 [23] Bradner, S., "Key words for use in RFCs to Indicate Requirement 764 Levels", RFC 2119, March 1997. 765 [24] Mitton, D., and Beadles, M., "Network Access Server 766 Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, 767 July 2000. 768 [25] Abboba, B., and Beadles, M., "The Network Access Identifier", 769 RFC 2486, January, 1999. 770 [26] Thomas, S., and Narten, T., "IPv6 Address Stateless 771 Autoconfiguration", RFC 2462, December, 1998. 773 14.0 Author's Contact Information 775 James Kempf Phone: +1 408 451 4711 776 DoCoMo Labs USA Email: kempf@docomolabs-usa.com 777 180 Metro Drive, Suite 300 778 San Jose, CA 95430 779 USA 781 Craig Gentry Phone: +1 408 451 4723 782 DoCoMo Labs USA Email: cgentry@docomolabs-usa.com 783 180 Metro Drive, Suite 300 784 San Jose, CA 95430 785 USA 787 Alice Silverberg Phone: +1 614 292 4975 788 Department of Mathematics Email: silver@math.ohio-state.edu 789 Ohio State University 790 Columbus, OH 43210 791 USA 793 15.0 Full Copyright Statement 795 Copyright (C) The Internet Society (2002). All Rights Reserved. 796 This document and translations of it may be copied and furnished to 797 others, and derivative works that comment on or otherwise explain it 798 or assist in its implementation may be prepared, copied, published 799 and distributed, in whole or in part, without restriction of any 800 kind, provided that the above copyright notice and this paragraph 801 are included on all such copies and derivative works. However, this 802 document itself may not be modified in any way, such as by removing 803 the copyright notice or references to the Internet Society or other 804 Internet organizations, except as needed for the purpose of 805 developing Internet standards in which case the procedures for 806 copyrights defined in the Internet Standards process must be 807 followed, or as required to translate it into languages other than 808 English. The limited permissions granted above are perpetual and 809 will not be revoked by the Internet Society or its successors or 810 assigns. This document and the information contained herein is 811 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 812 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 813 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 814 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 815 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 817 16.0 IPR Statement 819 DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs) hereby 820 declares that it is in conformance with Section 10 of RFC 2026. 821 Contributions of DoCoMo USA Labs may contain one or more patents or 822 patent applications. To the extent that the contribution of DoCoMo 823 USA Labs is adopted to the specification, DoCoMo USA Labs undertakes 824 to license patents technically necessary to implement the 825 specification on fair, reasonable and nondiscriminatory terms based 826 on reciprocity.