idnits 2.17.1 draft-hoare-nics-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 326 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Graydon Hoare 2 draft-hoare-nics-00.txt 3 expires July 15 1997 Jan 15 1997 5 NICS 6 Network of Identifier and Credential Servers 7 (first public draft) 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress". 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 NICS is a proposed system which meets the requirements of large- 30 scale, unique principal identification, for use in conjunction with 31 an arbitrary set of security systems such as have been proposed by 32 members of the IETF. 34 This proposal outlines the motivation for the development of NICS, 35 and gives a general description of its internal workings and 36 interfaces with higher-level protocols. 38 It should be emphasized up front that NICS is not a complete 39 security system, nor does it aim to replace any existing components 40 of the internet which already work. The design draws off the fact 41 that many security systems already have flexible name schemes, and 42 are therefore considered components which are used in conjunction 43 with NICS to achieve an improved level of service, flexibility and 44 reliability, while introducing many desirable features such as 45 anonymous identifiers, self-optimization, and low-overhead 46 operation. 48 For the purpose of initial evaluation, the remainder of this paper 49 is short and to the point, and requires a little work on the 50 reader's side to understand the reasoning. Additional discussion is 51 welcome on the mailing list. 53 jan 15 1997 draft-nics-00.txt graydon hoare 55 Rationale 57 The intent of the author is to produce a stable, self-maintaining 58 distributed database capable of identifying (naming) an extremely 59 large number of principals and providing their credentials to any 60 principals who ask. Such an intent initially appears to overshadow 61 pre-existing systems such as DNS, X.500, SDSI, etc. However this is 62 not the case: all currently existing naming schemes allow for, or 63 require at some point in their operation a unique, unchanging 64 reference name for a given principal. Currently existing standards 65 to refer to each other by default: SDSI imports global names out of 66 the DNS, X.500 imports names out of the MX map of the DNS, DNSSEC 67 imports names from X.500/509 names, or from IP numbers etc. None of 68 these exported names are static, or even acceptably detached from 69 real-world organizational structures. Most standards also allow for 70 additional naming schemes. NICS is an attempt to define such a 71 naming scheme on which all others may optionally be built, or on 72 which low-overhead security services may directly operate. NICS does 73 not guarantee anonymity in all cases, nor does it guarantee any sort 74 of directory service. The design does not specify a security 75 framework -- the issue is implementation specific. The only feature 76 NICS adds to the internet is strong universal naming, for purposes 77 of customization, accounting, authentication, authorization, and 78 other ``security'' procedures. It is beyond the scope of this 79 initial document to describe these procedures further; the reader is 80 assumed to be familliar with modern security systems. 82 Design 84 NICS is a system for serving the values of a single relating table 85 to anyone connected to the global internet. The table consists of 86 identifiers (which uniquely identify communicating principals) and 87 their associated credentials. This is called the NICS Database. It 88 is served by Identifier and Credential Servers (ICSs). The format 89 for NICS IDentifiers (NIDs) is specific and fixed: they are all 16- 90 bytenetwork order unsigned integers. The numeric space afforded by 91 16bytes is immense, as no NIDs go unused within NICS. In 92 comprehensible terms, a 128-bit length would allow each of 6 billion 93 people to allocate 1 billion new NIDs every milisecond of the day 94 for 1.8 million millennia before the range is exhausted. It is 95 therefore suggested that 16 bytes is sufficient even for the large 96 task of unique identification. 98 The format for credentials is variable, but each type of credential 99 must conform to the following criteria: 101 * it must be possible to encode, transmit and store the credentials 102 as a string of bytes (octets) 104 jan 15 1997 draft-nics-00.txt graydon hoare 106 * the standard from which the credentials are derived must be 107 recognized and numbered by IANA. 109 Every principal within NICS is represented solely by its NID. A 110 principal uses its NID and its associated credentials to establish 111 any further relationships, but the basic NICS record is just a NID - 112 > Credential mapping called a Principal Record (PR). 114 An ICS will use credentials within its local database to evaluate 115 and authenticate transactions with other principals, including other 116 ICSs. It is therefore essential that at minimum an ICS maintains its 117 own PR in a safe, local store. 119 The database is distributed amongst all known ICSs in a non- 120 hierarchical maner. It is devided amongst hosts by using Scopes. A 121 scope is stored as a tuple of 1 low NID and 1 high NID, which 122 together represent an inclusive numeric range. A scope is associated 123 with the NIDs of one or more ICSs acting as replication-peers for 124 that scope in a structure called a Service Record (SR). Every ICS in 125 an SR's peer table is responsible for storing a copy of every 126 allocated PR within the Scope. A change to a PR within a scope can 127 be initiated by any SR-peer, and inter-peer synchronization is 128 achieved through flooding of timestamped advisory locks and a simple 129 commit/rollback scheme. Any peer in an SR is responsible for 130 maintaining an accurate map of the SR, as well as an accurate map of 131 the 2 SRs with ranges immediately ``above'' and ``below'' the SR. If 132 a peer is a member of more than one SR (as will often be the case) 133 it must maintain these records for each SR independently. For every 134 change to a PR or SR, every peer in the SR-peer list needs to 135 acknowledge the change. SR updates should additionally flood into 136 the neighbouring SRs, although acknowledges from neighbours may be 137 delayed or ignored. 139 Each SR has an implicit ``desired distribution'' which is calculated 140 based on its breadth of scope, among other things. The desired 141 distribution is the ideal number of hosts on which the scope should 142 be replicated in order to be considered reliable and fast -- 143 obviously the calculation will need to take into account a few 144 factors. Every peer within an SR communicates the size of its 145 remaining allocated local storage to every other peer. Expansion of 146 an SR towards its desired distribution takes place using the 147 standard ICS flooding transaction method. An ICS will introduce a 148 new ICS into an SR that it is a member of, if and only if 150 * the desired distribution for the SR has not yet been met 152 * the new ICS has more free space available than any other willing 153 neighbours 155 jan 15 1997 draft-nics-00.txt graydon hoare 157 The first ICS within an SR to reach its highwater mark in allocated 158 storage (which should be well beneath its real limit, as extra space 159 is needed in panic situations) signals its peers that it is running 160 out of space, and it is time for a ``split'' transaction. The SR 161 then splits at a NID specified by the initiating peer, and a new SR 162 is created beginning at the split NID + 1. The new SR excludes the 163 initiating peer. This split takes place on all peers in the SR. The 164 appropriate ``above'' and ``below'' SRs are adjusted, and the newly 165 split scope goes about its top priority which is always to reach the 166 desired distribution. 168 A peer may, at any time, ``resign'' from an SR provided the SR has 169 other active peers. In the unlikely event that all peers in an SR 170 resign or are disconnected in rapid succession, the neighbours of 171 the SR will be made aware of the fact, and are obliged to offer 172 assistance in transferring the portion of the database off the 173 crashing servers. 175 Aggregation may take place using an as-of-yet undecided strategy. 176 Since all peers within an SR are always aware of the NIDs of all 177 neighbouring peers, it is not difficult to imagine a strategy of SR- 178 boundary re-alignment in order to aggregate SRs. It should be 179 stressed however that stability through replication takes priority 180 over optimizing aggregations. 182 Any query which enters an ICS is answered by taking the following 183 steps (assuming principal authentication) 185 * If the PR is stored locally, return the credentials of the query 187 * Otherwise, forward the query to a random member of the SR with the 188 closest known range. 190 In these cases, forwarding can mean either returning the SR to the 191 client or actually performing a recursive query, much like DNS. 192 Usually a recursive query will yield better results. Anyone is 193 allowed to cache SRs, so locating an appropriate server should not 194 take too long. PRs are not intended to be cached unless they are 195 flagged with a special loose-security bit, which enables cached PRs 196 to use TTLs for cache-consistency. Any PR without the loose-security 197 bit set may be cached, but must have at minimum its hash-value 198 reloaded from an authoritative peer every time it is required by 199 another layer of the system. It will be hard to enforce this rule, 200 but adherance is recommended in order to close any possible windows 201 for attackers. In order to remain reasonably efficient in spite of 202 the heavy consistency requirements, the communication protocol must 203 be lightweight, and the cache of SRs much be as large as possible in 204 clients. 206 jan 15 1997 draft-nics-00.txt graydon hoare 208 For update messages, the query is processed in a timestamped, 209 flooded two-phase commit, in which a transaction only proceeds after 210 a signed cookie is received from all peers in the SR. If an SR peer 211 is ever ``unreachable'', it is flagged as down and all commits are 212 assumed to be approved by it. If the peer ever comes back up, in 213 order to clear its down flag it must take whatever measures 214 necessary in requested transfers to provide to all members of the SR 215 with a signed digest of the most recent version of the SR. In the 216 interim, the SR may have abandonned the peer altogether and expanded 217 to the desired distribution using other peers. In such a case the 218 host is informed of its exclusion upon resuming contact with its old 219 SR. A peer is expected to abide by such a decision. 221 There is no defined means (yet) for dealing with multiple sets of 222 peers who consider one another mutually exclusive. One SR must yield 223 control of the given range to the other. Otherwise a ``shadow NICS'' 224 emerges, much like the ``alternative'' domain name servers, except 225 that no integration is possible because there is supposedly only one 226 NID range. Such activity would therefore only be destructive to both 227 sets of peers, as they would no longer be able to distinguish which 228 NID was which. While such activity could be used as a means of 229 attack, sufficient CA data communicated out of band makes this 230 easily defended against. 232 Finally, announcement of an ICS proceeds exactly as does 233 announcement of any other principal: the principal sends a broadcast 234 challenge for valid authentication over its local link. The 235 challenge uses either its own previously-established PR or an out of 236 band PR. Any valid response it receives has proven itself to be 237 attached to the wider NICS, and it therefore added to the client's 238 list of local ICSs. If no response is received, a larger broadcast 239 may be necessary, or the use of some service-location protocol. If 240 an out of band PR is chosen, the next request will probably be a 241 query to set a new NID for the principal. Such a query is forwarded 242 a random number of times to random peers within the NICS and 243 eventually serviced (perhaps after a TTL expires) by assigning the 244 next consecutive NID in a scope with free space. NIDs are assigned 245 consecutively within scopes starting from a randomly chosen position 246 and overflowing onto the low end of the scope if necessary (in order 247 to better permit aggregation) but since scopes shift from one server 248 to another the actual value of a NID does not reveal any practical 249 information about the principal posessing it. 251 In fact, this is the primary motivation for NICS: principals may 252 have as many unassociated and (to varying degrees) anonymous NIDs as 253 they feel they need to maintain privacy. If a NID ever outlives its 254 usefulness, its PR may be set to NULL at which point no further 255 modifications are authorized to take place. It is ``dead''. It is 256 the responsibility of the principal to keep joinable data out of 258 jan 15 1997 draft-nics-00.txt graydon hoare 260 their PR, and out of the hands of anyone they do not wish to trace 261 them, but under NICS it actually is an option to have anonymous 262 identities. 264 Implementation 266 At this time, no implementation is available. The author has begun 267 work on a portable ANSI C version of an ICS, but it will most likely 268 need to be rewritten several times in order to conform to emerging 269 GSSAPI & IPSEC standards. Most of the code required for such a 270 server has already been written -- there are libraries to handle 271 most authentication schemes, simple database management, caching, 272 and network communication. It should be stressed that NICS is 273 intended to be capable of operating in an extremely low-overhead 274 system, such as a consumer electronics device or embedded 275 controller. Several scenarios do not even include mutual 276 authentication -- systems relying on smart-cards or even magnetic 277 strip cards may benefit from a uniform identifier scheme. 279 In order to make NIDs easier to remember, certain transformations 280 are suggested such as mapping 16-bit chunks into a dictionary of 281 standard english words. A 2^16 entry dictionary was prepared as a 282 demonstration. 284 The random NIDs (in 2^16 decimal chunks) 286 * 56184.10819.11346.28658.8732.65087.5944.14558 287 * 38012.49371.6317.16111.20713.58321.55011.48691 288 * 6887.1175.33979.52356.53123.62765.14518.24799 290 map to 292 * sucks.claw.coefficient.incredible.capioma.yountsville.bmw.dedeaux 293 * misery.rillton.bootstraps.dome.flandry.tick.squeaky.renshaw 294 * breathes.aliquid.liveware.shackleton.sides.ways.declez.gulph 296 which, while not exactly easy to remember, are better than their 297 decimal counterparts. Such identifiers can be stored within any 298 other security system easily as extended name types, revealing as 299 little as is desired (or knowable) about the principal. 301 Further comments on NICS can be directed to the IPSEC mailing list 302 or to the author at graydon@pobox.com.