idnits 2.17.1 draft-van-beijnum-multi6-cbhi-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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ODT]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 2004) is 7406 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: 'M6SEC' is defined on line 302, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) -- Possible downref: Non-RFC (?) normative reference: ref. 'ODT' == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-noid-00 -- Possible downref: Normative reference to a draft: ref. 'NOID' == Outdated reference: A later version (-02) exists of draft-nordmark-multi6-threats-00 ** Downref: Normative reference to an Informational draft: draft-nordmark-multi6-threats (ref. 'M6SEC') -- No information found for draft-odell-8 - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ODELL96' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft I. van Beijnum 2 Document: draft-van-beijnum-multi6-cbhi-00.txt January 2004 3 Expires: July 2004 5 Crypto Based Host Identifiers 7 This document is an Internet-Draft and is subject to 8 all provisions of Section 10 of RFC2026. 10 Internet-Drafts are working documents of the Internet Engineering 11 Task Force (IETF), its areas, and its working groups. Note that 12 other groups may also distribute working documents as 13 Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/1id-abstracts.html 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html 27 Abstract 29 This memo specifies a 64-bit crypto-based host identifier that can 30 be used as an interface identifier in protocols that allow address 31 agility, such as [ODT]. The cryptographic nature of the host 32 identifier makes it possible to determine whether a correspondent 33 is legitimately using said host identifier or not. 35 The host identifiers can be used as regular interface identifiers 36 in protocols that don't require an identifier that is separate from 37 locators, or they can be expanded to 128-bit IPv6 address like 38 values for use with protocols that do need such an identifier-only 39 value. 41 1. Introduction 43 In many types of interactions across the network it is important to 44 know the identity of the correspondent. This is especially true in 45 multihoming and mobility, where a correspondent may change its 46 address during a session. In [MIPv6], [NOID] and [ODT] it has been 47 shown to be possible to solve mobility and multihoming without 48 introducing a long-lived host or stack name identifier. However, 49 this doesn't mean that having such an identifier would be without 50 benefits. This document explores the possibility of adding a means 51 to identify a host independent of the full IPv6 address used by the 52 host and independent of a specific multihoming or mobility 53 solution. 55 2. Overview 57 There are two types of crypto-based host identifiers 64 bit and 80 58 bit. The 64 bit type consists of 4 control bits, 48 site key bits 59 and a 12 bit host number: 61 0 8 16 24 32 40 48 56 63 62 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 63 | site |C | site (continued) | host | 64 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 66 The 64 bit host identifiers are appropriate in cases where the 67 subnet bits (bits 48 - 63 in the IPv6 address) are subject to 68 change, for instance in a host multihoming or mobility situation. 69 When the subnet bits are fixed, which is likely to be the case with 70 site multihoming or when no address changes are expected, 80 bit 71 host identifiers that include the subnet bits are more appropriate, 72 as these allow significantly more hosts to be grouped together in a 73 site. The 80 bit host identifier consists of 4 control bits, 44 74 site key bits, a 16 bit host number and a 16 bit subnet number: 76 0 8 16 24 32 40 48 56 64 72 79 77 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 78 | subnet | site |C | site (continued) | host | 79 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 81 The control bits are: 83 - reserved 84 - 80 bit identifier (1) or 64 bit identifier (0) 85 - u/l and g bits as outlined below 87 3. EUI-64 Compatibility 89 Generally, a host will create IPv6 addresses for interfaces based 90 on the interface's EUI-64 as outlined in [RFC 2462]. In order to 91 avoid overlap from addresses generated by [RFC 3041] and from 92 regular EUI-64 interface identifiers, for crypto-based host 93 identifiers the universal/global bit is set to "universal" and the 94 group bit is set to indicate a group (multicast) address. Note that 95 the resulting EUI-64 value is only valid for the purposes of 96 generating IPv6 addresses in accordance with [RFC 2462]. Under no 97 circumstances may such a value be assigned to an interface for use 98 as a link address. 100 4. The Site Identifier 102 The site identifier is created by generating a key pair using a 103 public key crypto algorithm (to be decided). Then the SHA-1 104 algorithm is used to calculate a hash over the public key. If 80 105 bit host identifiers are to be used, the site identifier consists 106 of the first 44 bits of the SHA-1 hash. If 64 bit host identifiers 107 are to be used, the site identifier consists of the last 48 bits of 108 the SHA-1 hash. (The terms "site identifier" and "site key bits" 109 are used interchangeably.) 111 All hosts that hold a host identifier must have a set of public key 112 cryptographic keys. The host's public key is signed using the site 113 secret key. 115 Site identifiers, along with the full self-signed public key and 116 other pertinent information, are registered publicly to avoid and 117 resolve site identifier collisions. When a newly generated site 118 identifier collides with an existing one, the new key pair is 119 discarded and a new one is generated. This is the only required use 120 of a public registry. All other use of such a registry is optional. 122 Since it is computationally expensive to generate working keys that 123 match a specific site identifier, possession of the secret key 124 provides a "proof of ownership" of a site identifier that is good 125 enough to fend off denial of service attacks and to provide 126 authentication with a strength level somewhere between a simple 127 encrypted password and full-out IPsec. An important feature is 128 that the site identifier registry doesn't require rooted authority: 129 any mechanism that makes a full list of site identifiers and public 130 keys along with serial numbers available to anyone who wants to do 131 a lookup within a reasonable timeframe after new identifiers have 132 been generated is sufficient. A small number of repositories that 133 accept new site identifiers and accompanying material after 134 checking the signature would work well. Each repository could work 135 independently but they could exchange new site identifiers for the 136 sake of completeness. Repositories can then make their contents 137 available through mirroring and direct querying mechanisms. A good 138 way to allow direct queries to the site identifier database would 139 be by publishing a copy of an up to date repository in the DNS. 141 A fully populated 44 or 48 bit range of values is too large to 142 store in the DNS without additional hierarchical structure. 143 However, these ranges will never be fully populated, both because 144 such a large number of site identifiers isn't necessary and because 145 at some point, the chance of successive collisions becomes too 146 large to be able to generate a new site identifier efficiently. A 147 target for optimum performance would be a population somewhere 148 between one in a million (approximately 17 million and 260 million 149 site identifiers respectively) and one in a thousand (17 / 260 150 billion site identifiers). Current practice shows that the DNS can 151 handle flat spaces with up to several tens of millions entries, so 152 a modest growth rate (well below Moore's Law) maxing out at around 153 one to ten billion sites in 2050 shouldn't be a problem. 155 5. The Challenge/Response Mechanism 157 When a host wants to authenticate a correspondent using a 158 crypto-based host identifiers, it issues a challenge to the 159 correspondent. The layout of the challenge and the way it is 160 transmitted to the correspondent is to be decided later. 162 When checking a response, a host may optionally take advantage of 163 information published in the DNS or through other means. This 164 allows the host to detect whether it's dealing with the "real" 165 holder of a site locator rather than an impostor that stumbled on a 166 key pair that maps to an existing site identifier. It also allows 167 for retiring a compromised host key: if the published site serial 168 number is higher than that presented by the correspondent, the host 169 key is invalid. 171 6. Turning the Site Identifier into an Address Range 173 In certain types of multihoming solutions, such as [ODELL96], the 174 locator and identifier functions of the IP address are separated. 175 In these cases, the upper layer protocols such as TCP and UDP only 176 see the identifier. In [ODELL96] the identifier consists of the 177 lower 64 bits of the IPv6 address, which is compatible with what is 178 proposed here. However, intra-site connectivity using just the 179 lower 64 bits of the IPv6 address is problematic. To avoid this 180 problem, and in order to provide a range of stable addresses a site 181 may use regardless of its connectivity to the Internet, the site 182 identifier may be transformed into a site prefix. 184 The procedure for transforming a 80 bit host identifier into a site 185 prefix is to take the site identifier bits and concatenate those to 186 a 4 bit prefix assigned by IANA. The resulting 48 bit value is the 187 provider independent site prefix. This prefix is combined with a 80 188 bit host identifier to form a complete IPv6 address. 190 Example of how a 80 bit host identifier is turned into a 48 bit 191 site prefix: 193 0 8 16 24 32 40 48 56 64 72 79 194 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 195 | subnet | site |C | site (continued) | host | 196 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 197 \ \ | | 198 \ \| | 199 +--+--+--+--+--+--+--+--+--+--+--+--+ 200 |IA| s i t e i d e n t i f i e r | 201 +--+--+--+--+--+--+--+--+--+--+--+--+ 202 0 8 16 24 32 40 47 204 (IA = 4 bit prefix assigned by IANA) 206 A 64 bit host identifier is turned into a site prefix by 207 concatenating the site bits with a 12 bit prefix assigned by IANA. 208 This results in a 60 bit provider independent prefix. To avoid 209 being limited to a single subnet, the top 4 bits of the host number 210 are copied to bits 60 - 63 in the IPv6 address. The full 64 bit 211 host identifier is present in the lower 64 bits to arrive at a full 212 IPv6 address. This allows for 16 subnets with 256 possible hosts 213 each. 215 Example of how a 64 bit host identifier is turned into a 60 bit 216 site prefix / 64 bit subnet prefix: 218 0 8 16 24 32 40 48 56 63 219 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 220 | site |C | site (continued) | host | 221 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 222 \ \ | | 223 \ \| | 224 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 225 | IANA | s i t e i d e n t i f i e r |H | 226 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 227 0 8 16 24 32 40 48 56 63 229 (IANA = 12 bit prefix assigned by IANA) 230 (H = top 4 bits of the host number) 232 Use of an EUI-64 that isn't a host identifier as outlined in this 233 document in combination with one of the above provider independent 234 prefixes is undefined and not recommended. 236 7. Operational Overview 238 If the host identifiers described here are used with ODT, then the 239 ODT challenge/response interactions are changed as follows. A and B 240 are hosts communicating using ODT, holding addresses A1, A2 and B1, 241 B2 respectively. After A sees an address change from B1 to B2 in 242 incoming packets, it issues a challenge to B. Note that unlike with 243 unmodified ODT there is no need to perform ODT interactions before 244 a change of address happens, although a highly security conscious 245 implementation may want to do so anyway. 247 When A wants to challenge B, it needs to encrypt a nonce using B's 248 public key. If A doesn't have B's public key yet, it requests B's 249 public key which must be signed by the site key, along with a copy 250 of the site public key. A then checks whether the site identifier 251 bits are indeed the same as the truncated hash derived from B's 252 site public key, and if so, uses the site public key to check the 253 signature over B's public key. If this procedure succeeds, A has 254 B's public key so it can encrypt a nonce and send it to B. B 255 decrypts the nonce and returns it to A. When A receives back the 256 nonce, it knows that B holds the matching private key so B's 257 identity is verified. 259 8. IANA Considerations 261 IANA is requested to allocate a /4 and a /12 for crypto-based site 262 identifier derived provider independent address ranges. 264 9. Security Considerations 266 Since the length of the hash over the public key is only 44 or 48 267 bits, even though finding a key for a known hash is extremely 268 difficult, there is a significant chance of accidental collisions. 269 As such, this authentication scheme on its own isn't secure enough 270 for use with very sensitive applications. 272 10. Author's Address 274 Iljitsch van Beijnum 275 Karel Roosstraat 95 276 2571 BG The Hague 277 Netherlands 279 Phone: +31-70-3103790 281 Email: iljitsch@muada.com 283 11. References 285 [RFC 2462] S. Thomson and T. Narten, "IPv6 Stateless Address 286 Autoconfiguration", December 1998 288 [RFC 3041] T. Narten and R. Draves, "Privacy Extensions for 289 Stateless Address Autoconfiguration in IPv6", 290 Januari 2001 292 [ODT] I. van Beijnum, "On Demand Tunneling For 293 Multihoming", work in progress, January 2004 295 [MIPv6] "Mobility Support in IPv6", 296 draft-ietf-mobileip-ipv6-24.txt, work in progress 298 [NOID] E. Nordmark and T. Li, "Multihoming without IP 299 Identifiers", draft-nordmark-multi6-noid-00.txt, 300 work in progress, October 2003 302 [M6SEC] Nordmark, E., and T. Li, "Threats relating to 303 IPv6 multihoming solutions", 304 draft-nordmark-multi6-threats-00.txt, work in 305 progress, October 2003. 307 [ODELL96] O'Dell M., "8+8 - An Alternate Addressing 308 Architecture for IPv6", draft-odell-8+8-00.txt, 309 work in progress, October 1996