idnits 2.17.1 draft-ietf-ids-ph-04.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-25) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** Expected the document's filename to be given on the first page, but didn't find any ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 474 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- 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) -- Missing reference section? 'KRB5' on line 708 looks like a reference -- Missing reference section? 'GSS-API' on line 705 looks like a reference -- Missing reference section? 'HMAC' on line 706 looks like a reference -- Missing reference section? 'TLS' on line 711 looks like a reference -- Missing reference section? 'SSL' on line 709 looks like a reference -- Missing reference section? 'SSH' on line 710 looks like a reference -- Missing reference section? 'IPSEC' on line 707 looks like a reference -- Missing reference section? '-' on line 834 looks like a reference -- Missing reference section? 'CRLF' on line 872 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDS Working Group Roland Hedberg 3 INTERNET-DRAFT Umea University 4 Paul Pomes 5 QUALCOMM, Inc 7 The CCSO Nameserver (Ph) Architecture 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 months 17 and may be updated, replaced, or obsoleted by other documents at any 18 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 ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 The Ph Nameserver from the Computing and Communications Services 30 Office (CCSO), University of Illinois at Urbana-Champaign has for 31 some time now been used by several organizations as their choice of 32 publicly available database for information about people as well as 33 other things. It is now widely felt that the Internet community 34 would benefit from having a more rigorous definition of the client- 35 server protocol. This document will hopefully achieve that goal. 36 The Ph service as specified in this document is built around an 37 information model, a client command language and the server 38 responses. 40 1. Overview 42 1.1. Basic Information Model 44 At its simplest the Ph database can be thought of as a computer- 45 resident "phone book". However, it can be used to collect arbitrary 46 information about people or things, and in response to a query about 47 an object named in the database, return information about that 48 entity. It is in short a nameserver for people and objects. It was 49 designed to keep a relatively small amount of arbitrary information 50 about a relatively large number of people or things, and provide 51 access to that information over the Internet. In order to structure 52 the information the manager of the database has to decide which views 53 to present of the real-world objects that are to be represented in 54 the database. Each view is then composed of a number of fields and 55 their values. To support this concept Ph has the notion of named 56 information, i.e., categorizing information into what are called 57 fields and assigning descriptive names to those fields. 59 Even if the database resides and is reachable from the Internet it is 60 local in the meaning that no server is supposed to be able to refer a 61 client to another server which might hold the wanted information. 62 However a server may contain a list of other Nameservers which can be 63 used by clients to query other Nameservers for information. 65 1.1.1. Fields 67 A field descriptor is associated with each field and is used to 68 describe the type and behavior of the field. A field descriptor 69 includes the fieldname, the maximum length of information the field 70 can store before truncation, keywords describing the properties of 71 the field as well as free text describing what kind of information 72 the field is supposed to hold. 74 The keywords can be any of the following: 76 Always: Forces the field's contents to be always printed in addi- 77 tion to whatever fields specified by the query. 79 Any: This field is always searched by queries. To be most use- 80 ful, a field marked as Any should also have the Indexed and 81 Lookup keywords as well. 83 Change: Can be changed by the owner of the entry. 85 Default: Printed if no return clause is given in the query. 87 Encrypt: Must be encrypted before transmission. 89 ForcePub: Viewable/searchable regardless of the content of the 90 suppress field 92 Indexed: Fields that are kept track of in the database's index for 93 efficient lookups. At least one indexed field must be 94 present in each query. 96 LocalPub: May be viewed by anyone in the "local" domain or address 97 space. Fields with this keyword are completely invisible 98 outside of the "local" domain. They will not be shown with 99 the fields command (section 3.3), and are disallowed in 100 query commands or return clauses (section 3.8). 102 Lookup: May be used in the selection part of a query. A Field 103 without this keyword may not be used to select entries. 105 NoMeta: Wildcard searches are disallowed. 107 NoPeople: No entry of type "person" may include this field. 109 Private: Field may be viewed by Heros (section 1.4) only. 111 Public: May be viewed by anyone. Fields not marked with this key- 112 word may only be viewed by the entry's owner or a Hero. 114 Sacred: Changes to the field are prohibited except via non-network 115 invocations of the server, i.e., from a tty, file, or pipe. 117 Turn: Users may turn off visibility of a field to everyone except 118 themselves and Heros by prefixing the field text with '*'. 120 Unique: Any change to the field will be rejected if the change 121 causes the modified field to match the same field in any 122 other entry. 124 1.1.2. Character Sets 126 Historically Ph has been restricted to only handle printable charac- 127 ters, that is characters with hexadecimal values between 0x20 and 128 0x7f. Lately with the spreading of 8-bit clean Operating Systems 129 there is no reason to keep this limitation. 131 This document therefore proposes that ISO-8859-1 shall be regarded as 132 an alternative character set for Ph, the default still being US- 133 ASCII. 135 Clients that utilize ISO-8859-1 should request that the server return 136 ISO-8859-1 by using the "set"-command. 138 In the instance that values are stored using ISO-8859-1 and are to be 139 shown to a client expecting US-ASCII, the characters with character 140 codes outside of the US-ASCII range should be displayed in the 141 "Quoted-Printable" content-transfer-encoding form defined in RFC- 142 2045. 144 1.2. Standardization issues 146 Each Nameserver manager is in essence free to name new fields to suit 147 the special needs of his/her organization. But in order to make the 148 directory service useful outside of the organization it is recom- 149 mended that a core set of standard fields always should be present. 151 Therefore this document defines a couple of standard collections of 152 fields (Appendix A). 154 Also note that the architecture makes no assumption about the search 155 and retrieval mechanisms used within individual servers. Operators 156 are thereby free to use any kind of dedicated databases, fast index- 157 ing software or even gateways to other directory services to store 158 and retrieve the information, if desired. 160 Ph simply functions as a known front-end, offering a simple data 161 model in addition to a well known port and simple query language. 163 1.3. Conventions Used in this Document 165 In examples, "C:" and "S:" indicate lines sent by the client and 166 server respectively. 168 1.4. Heros 170 For Ph a Hero is equivalent to a superuser or operator. Being in 171 Hero mode means that some or all artificial limits are removed; full 172 Heros may change any field in any entry in the database, as well as 173 view as many entries as they wish. Heros can also be limited to one 174 field of one other entry. Hero mode is used mostly for administra- 175 tive purposes, delegation of group authority over selected fields, 176 and is controlled by the acl field. 178 2. Basic Operation 180 Initially, the server host starts the Ph service by listening on TCP 181 port 105. When a client host wishes to make use of the service, it 182 establishes a TCP connection to the server host. The client and the 183 Ph server then exchange commands and responses (respectively) until 184 the connection is closed or aborted. 186 2.1. Command syntax 188 Commands in Ph consist of a keyword optionally followed by zero or 189 more keywords or values, separated by spaces, tabs or newlines, and 190 followed by a carriage return-linefeed (CRLF) pair. A more thorough 191 description using BNF is given in Appendix C. 193 Values containing spaces, tabs or newlines must be enclosed in double 194 quotes ('"'). In addition the sequences "\n", "\t","\"" and "\\" may 195 be used to mean newline, tab, double quote and backslash, respec- 196 tively. 198 Keywords must be given in lower case; case in the values of fields is 199 preserved, although queries are not case-sensitive. 201 2.2. Response syntax 203 Responses consist of a result code followed by additional information 204 possibly separated by entry index and/or field name and are ter- 205 minated by a CRLF pair. 207 result code:[entry index:][field name:]text 209 Responses to some commands might be multi-lined. In these cases each 210 line in the response, except the last, has the appropriate result 211 code negated (prefaced with "-"). The last line then starts with the 212 appropriate result code without negation. Each line must be ter- 213 minated by a CRLF pair. 215 If a particular command can apply to more than one entry, then the 216 multilined response must be so organized that all information per- 217 taining to each entry is returned on consecutive lines, and that each 218 of those lines must have one and the same entry index directly fol- 219 lowing the resultcode. The first entry index should be 1 and incre- 220 mented each time a new entry is referred to. 222 C: query hedberg return email name title 223 S: 102:There were 3 matches to your request. 224 S: -200:1: email: canheg95@student.umu.se 225 S: -200:1: name: Carl Johan Hedberg 226 S: -200:1: title: Student 227 S: -200:2: email: parheg95@student.umu.se 228 S: -200:2: name: Par Hedberg 229 S: -200:2: title: Student 230 S: -200:3: email: Roland.Hedberg@umdac.umu.se 231 S: -200:3: name: Roland Hedberg 232 S: -200:3: title: Boss of the Network group 233 S: 200:Ok 235 Commands that can apply to more than one field must have the name of 236 the field to which the response applies directly following the entry 237 index. 239 The text of the response will be either an error message in human 240 readable format, or data from the Nameserver. Whitespace (spaces or 241 tabs) may appear anywhere in the response, but the field name and 242 text columns if present must each begin with a whitespace character. 244 Since more than one specific piece of information may be manipulated 245 by a particular command, it is possible for parts of a command to 246 succeed, while other parts of the same command fail. This situation 247 is handled as a single multi-line response with the result code 248 changing as appropriate. 250 As for FTP, the result codes are in the range 100-699 (or from -699 251 to -100 for multiline responses), where the leading digit has the 252 following significance: 254 1: In progress 255 2: Success 256 3: More information needed 257 4: Temporary failure; it may be worthwhile to try again. 258 5: Permanent failure 259 6: Phquery specific codes 261 Many commands generate more than one line of response; every client 262 should be prepared to deal with such continued responses. Note that 263 a command is finished when and only when the result code on a 264 response line (treated as a signed integer) is greater than or equal 265 to 200. 267 Clients should assume that any numeric response, within the above 268 mentioned ranges, are valid. Also note that the server is allowed to 269 send one or more lines with result codes between -199 - -100 (the 270 leading "-" indicates a continuation line) and 100 - 199, as status 271 information, before the actual results are transmitted. 273 2.3. Format of a search string 275 Matching is not sensitive to upper or lower case letters and is nor- 276 mally done on a word-by-word basis. That is, both the query expres- 277 sion and the entry information is broken up into words, and indivi- 278 dual words are compared using exact matching. If the order of the 279 words is important in a query, then the query string can be sur- 280 rounded by '"' (double quotes), whereby the complete search string is 281 matched against the information in the Nameserver database. 283 Word delimiters are the following characters: , , , ",", ";" and ":" . These characters are not indexed and 285 should not be part of the search string. 287 However, special symbols, called "wildcard" characters, can be used 288 if the exact spelling is unknown. The '*' (asterisk, 0x2A) is used 289 in place of zero or more characters, '+' (plus, 0x2B) in place of one 290 or more unknown characters, and '?' (question mark, 0x3F) can be used 291 when exactly one character is unknown. If the unknown character can 292 be one of a limited set this can be specified by surrounding the set 293 with brackets, e.g., [ei] means that in that place an 'e' or an 'i' 294 would match. 296 3. Commands 298 3.1. status 300 status 302 Prints the message of the day and the current status of the 303 nameserver. 305 C: status 306 S: 100:Qi server $Revision: 1.4 $ 307 S: 100:Ph passwords may be obtained at CCSO Accounting, 308 S: 100:1420 Digital Computer Lab, between 8:30 and 5 Monday-Friday. 309 S: 100:Be sure to bring your U of I ID card. 310 S: 200:Database ready 312 3.2. siteinfo 314 siteinfo 316 Returns information about the servers site. Possible fields are 318 Version Version information for the server. 319 Maildomain The mail domain to use for phquery-type mail. 320 Mailfield The field containing the specific email address. 321 Mailbox Mandatory entry that names the field to use as mail- 322 drop. 323 Administrator Guru in charge of service. 324 Passwords Person in charge of ordinary password/change requests. 325 Authenticate Authentication methods supported by the server, 326 ordered in the site-preferred way. Presently the fol- 327 lowing options are defined: 329 1 attempt auto login 330 2 allowed to be interactive if needed 331 4 use ANSI X9.9 challenge/response 332 8 use v4 Kerberos login 333 16 use v5 Kerberos [KRB5] login 334 32 use GSS-API [GSS-API] login 335 64 use email login 336 128 password encrypted response to challenge 337 256 use clear-text password 338 512 use HMAC [HMAC] with SHA-1 of challenge string 340 Example 342 C: siteinfo 343 S: -200:1:version:3.1 344 S: -200:2:maildomain:umu.se 345 S: -200:3:mailfield:alias 346 S: -200:4:mailbox:email 347 S: -200:5:administrator:roland.hedberg@umdac.umu.se 348 S: -200:6:passwords:roland.hedberg@umdac.umu.se 349 S: -200:7:authenticate:64:32:128 350 S: 200: Ok. 352 The mail fields in the siteinfo command direct how address informa- 353 tion stored in the Nameserver is to be used for delivering mail. 355 The specific (username, host) pair to where a user's mail should be 356 sent for final delivery is stored in the field named by {mailbox}. 357 Phquery and like utilities will use this field. 359 To construct a useable email address from Nameserver information, the 360 algorithm below is followed: 362 if ({maildomain} is not null) then 363 address = (contents of {mailfield})@{maildomain} 364 else 365 address = (contents of {mailfield}) 367 Some existing client software will not format email addresses 368 correctly if the value of {mailbox} is set to anything other than 369 "email" when {maildomain} is non-empty. 371 If {mailbox} is set to anything other than {email}, {maildomain} must 372 be reported empty by the siteinfo command. Also reformatting of each 373 record's {mailfield} must be done by the server before reporting it 374 to the client. 376 3.3. fields 378 fields [field ...] 380 Without an argument, a list of all available field descriptors should 381 be delivered. Any space-separated argument(s) restricts the list to 382 the named fields. Fields marked with the "LocalPub" keyword (section 383 1.1.1) should not be delivered outside of the local domain. 385 The output of the command consists of two lines describing each 386 field. The first line defines the field in technical terms (max 387 length and field attributes), while the second line is a brief 388 description of what the field is intended to hold. The second number 389 of each response is the field id number. 391 C: fields 392 S: -200:6:alias:max 32 Indexed Lookup Public Default 393 S: -200:6:alias:Unique name for user. 394 S: -200:3:name:max 64 Indexed Lookup Public Default 395 S: -200:3:name:Fullname 396 S: -200:2:email:max 128 Lookup Public Default 397 S: -200:2:email:Account to receive electronic mail. 398 S: -200:16:other:max 256 Lookup Public Default Change 399 S: -200:16:other:Other info the user finds important. 400 S: -200:33:home_phone:max 60 Lookup Public Change Turn 401 S: -200:33:home_phone:Home telephone number. 402 S: 200:Ok. 404 3.4. id 406 id information 408 Enters the given information in the Nameserver's log. This command 409 is used by the Ph client to enter the user id of the person running 410 it. 412 3.5. set 414 set [option[=value] ...] 416 Sets the named option for this nameserver session to a value. The 417 default string "on" is used if no value is supplied. Used without 418 arguments it return the settable options and their current value. 419 Some common options are 421 echo If on, echo the client's commands back to the client. 422 limit Changes that affect more than the specified number of 423 entries results in an error. 424 charset Return responses to the client in the character set speci- 425 fied. 426 verbose If on, report interim progress messages to the client. 427 addonly If on, change commands can only create fields in entries, 428 not modify them. 429 nolog If on, disable logging. 431 external If on, make Fields marked as "LocalPub" invisible. 433 Example 435 C: set verbose=off 436 S: 200:Done. 438 C: set 439 S: -200:echo:off 440 S: -200:limit:2 441 S: -200:charset:iso-8859-1 442 S: -200:verbose:off 443 S: -200:addonly:off 444 S: -200:nolog:off 445 S: -200:external:on 446 S: 200:Done. 448 3.6. login, logout, answer, clear, email, and xlogin 450 3.6.1. login 452 login [alias] 454 The "login" command allows client users to identify themselves to the 455 Nameserver. More specifically it identifies a client user with a 456 particular entry in the Nameserver and allows them to change fields 457 in that entry and possibly other entries. It is also necessary to be 458 logged in to the Nameserver to view certain sensitive fields in the 459 user's own entry. 461 In order to use the "login" command the client must prompt the user 462 for their ph alias and password. The client is then responsible for 463 (optionally) encrypting the password and sending it to the server. 464 This will be covered in sections 3.6.3 (answer) and 3.6.4 (clear). 466 C: login foo 467 S: 301:,:P"_Y$ONU%"SDUQ6&^`ZZ'?*#Y`A_.Z/A>?@SH>*- 469 3.6.2. logout 471 logout 473 The "logout" command allows a user who is logged in to the Nameserver 474 to logout. 476 C: logout 477 S: 200:Ok. 479 3.6.3. answer 481 answer encrypted-response 483 In response to the login command, the Nameserver responds with a ran- 484 dom challenge string. The Nameserver client encrypts the challenge 485 with the password supplied by the user, uuencodes the result into 486 US-ASCII, and returns the printable result in the "answer" command: 488 C: login ppomes 489 S: 301:.%$&.D^67$*1?<.2S@DR:Z@M*)AV-<:4QM>#R>M*HT 490 C: answer M5K'F:NI(a?M?O2+-a9`48RA#ZF=L9)G)/XRS7Q^0>0@-R7X$WGb`50B] 491 S: 200:ppomes:Hi how are you? 493 The encryption algorithm is based on a three rotor Enigma engine. 494 There are known attacks on the security of this approach. 496 The answer command is also used to return method-specific responses 497 to the xlogin command (section 3.6.6). 499 3.6.4. clear 501 clear cleartext-password 503 The "clear" command can be used instead of the "answer" command to 504 complete a login sequence. It's argument is the user's cleartext 505 password. This command is supplied only to support those clients 506 that have not implemented one of the encryption engines used by the 507 "answer" command. It's use is strongly discouraged. 509 C: login ppomes 510 S: 301:E=@Y&VW^_9YVI;D5.[EB0:B)9Z#_&X$:2)/eL$VJC87 511 C: clear MySecret 512 S: 200:ppomes:Hi how are you? 514 3.6.5. email 516 email local-userid 518 The "email" command can also be used instead of the "answer" command 519 to complete a login sequence. The value of local-userid is the 520 user's login name on the local machine. If all of the following con- 521 ditions are true, then the email command will be accepted by the 522 server: 524 1) The connection to the server originates on port 1023 or less on 525 the client. 527 2) The canonical name of the client's host matches the right-hand 528 side of the email address of the requested alias specified in 529 the "login" command. 531 3) The "local-userid" matches the left-hand side of the email 532 address belonging to the requested alias. 534 This is a weak but convenient form of authentication. Depending on 535 the information users are allowed to change about themselves and the 536 threat environment the server operates in, this method may be 537 appropriate. Servers should take care to avoid DNS spoofing. 539 3.6.6. xlogin 541 xlogin option alias 543 Extended login command for GSS, Kerberos v4 and v5, ANSI X9.9 token 544 devices (e.g., SNK/4), etc. The option is one of the values returned 545 in the Authenticate field of the "siteinfo" command (section 3.2). 546 Alias is the user's alias. 548 C: xlogin 16 ppomes 549 S: 301:DoKrbLogin started; send Kerberos mutual authenticator. 550 C: answer MJa8QO1cJHYz2IdWyg7uhAnixVqgCZQBWr64ciXYku1ktdu.... 551 S: 200:ppomes:Hi how are you? 553 C: xlogin 4 ppomes 554 S: 302:SNK Challenge "024142": 555 C: answer 82344338 556 S: 200:ppomes:Hi how are you? 558 The answer command returns the requested quantity, Kerberos authenti- 559 cator, X9.9 device response, etc. Binary quantities are first uuen- 560 coded into US-ASCII. 562 3.7. add 564 add field=value... 566 This command is used to add new entries to the database. You must be 567 logged in and have full Hero privileges (section 1.4) to use "add". 569 C: add name="doe john" id="123456789" alias="j-doe" 570 S: 200:Ok. 572 3.8. query 574 query [field=]value [field=value] . . . [return field1 [field2]] 575 If no field is specified together with a value then the field is 576 assumed to be "name" and/or "nickname". When more than one field- 577 value specification are given in a query, entries matching all 578 specifications are returned (implicit AND). 580 It is possible to define which fields should be returned by adding a 581 "return" clause. If no return clause is defined the Ph server will 582 return a default list of fields. Typical default fields are "alias", 583 "name", "title", "email", "phone", "address", "department", "www", 584 and "other". A return clause consists of the word "return" followed 585 by a list of fields or the word "all". If the word "all" is used 586 then all viewable fields will be returned. 588 C: query name=doe name=john 589 S: 102:There was 1 match to your request. 590 S: -200:1: alias: j-doe 591 S: -200:1: name: doe john 592 S: 200:Ok. 594 3.9. delete 596 delete [field=]value... 598 This command is used to delete entire entries from the database. You 599 must be logged in and have full Hero (section 1.4) privileges to use 600 "delete". 602 The arguments to the "delete" command are the same as the selection 603 part of a "query" command. "Delete" finds all the entries that match 604 the argument(s) and deletes them. 606 The "delete" command obeys the Nameserver "limit" option, which can 607 be used to prevent deletion of more entries than intended. 609 C: delete name="doe john" id="123456789" alias="j-doe" 610 S: 200:1 entries deleted. 612 3.10. change 614 change [field=]value [make|force] field="value"... 616 This command is used to change one or more fields in one or more 617 entries to the values specified. The "change" command consists of 618 two clauses, the "change" clause and the "make" or "force" clause. 619 The "change" clause determines which entries will be affected by the 620 command. It uses the same arguments as the selection clause of a 621 "query" command. The "make" or "force" clause specifies which 622 field(s) will be changed and the new value(s) of the specified 623 field(s). The "force" clause is only used to make non-encrypted 624 changes to fields marked "Encrypt". 626 You must be logged in to use "change". 628 The "change" command obeys the Nameserver "limit" option, which can 629 be used to prevent changing the field contents of more entries than 630 intended. 632 C: change alias=j-doe force password=NewSecret 633 S: 200:1 entry changed. 635 C: set limit=500 636 S: 200:Done. 637 C: change fax="(619) 555-1212" make fax="(760) 555-1212" 638 S: 200: 113 entries changed. 640 3.11. help 642 help [{native|client} [topic ...]] 644 Prints help on the Nameserver or on specific clients. If client is 645 specified, it should be a valid Nameserver client identifier, such as 646 "ph". The client-specific help will first be searched for topic, and 647 then the native help will be searched. If topic is omitted, a list 648 of all available help texts will be returned. If "native" or client 649 are also omitted, a list of clients will be returned. 651 C: help native 101 652 -200:1:101: 653 -200:1: The Nameserver echo option is set. The text of this response is 654 -200:1: the command you just gave, which has not (yet) been executed. 655 200:Ok. 657 3.12. quit/exit/stop 659 quit 661 Terminates the session with the Nameserver and causes the client to 662 exit. 664 C: quit 665 S: 200:Bye! 667 4. Security 668 4.1. Transport Layer 670 In the absence of encryption between client and server, all 671 Nameserver traffic is unsecure. Kerberos v4, v5, and the GSS-API all 672 provide encryption mechanisms, however the Nameserver protocol does 673 not support the means to negotiate encryption between client and 674 server. This implies that all traffic can be seen by other machines 675 having access to the network linking the client and server. Further- 676 more clear-text traffic is subject to modification in transit between 677 client and server. Possible ways of augmenting this would be to use 678 something like TLS [TLS], SSL [SSL], SSH [SSH], or IPSec [IPSEC]. 680 4.2. Server Authentication 682 Unless one of the mutual authentication mechanisms is used, e.g., 683 Kerberos 4/5 or GSS-API, there is no way to prove the identity of a 684 server. Further, there is no mechanism to prove a given server is 685 authoritative for a set of information. 687 4.3. Secure User Authentication 689 The Ph protocol allows the negotiation of several authentication pro- 690 tocols between client and server, some weak and some strong. It does 691 not prohibit the use of cleartext passwords, something which should 692 be depreciated, but is useful when dealing with some clients. 694 4.4. Privacy and Access Lists 696 Directory services like the CCSO white pages server that contain 697 information on persons have to consider privacy issues. This paper 698 describes one way of partitioning specific attributes from unwanted 699 access by designating them visible only to the "local" community, 700 visible only to the person connected with the information, or visible 701 only to the database administrator. 703 4.5. References 705 [GSS-API] RFC-2078 706 [HMAC] RFC-2104 707 [IPSEC] RFC-1825 708 [KRB5] RFC-1510 709 [SSL] In Internet Draft stage 710 [SSH] In Internet Draft stage 711 [TLS] In Internet Draft stage 713 5. Miscellaneous 714 5.1. Authors Addresses 716 Roland Hedberg 717 Umdac 718 Umea University 719 901 87 Umea 720 Sweden 721 723 Paul Pomes 724 Qualcomm Inc 725 6455 Lusk Blvd 726 San Diego, CA 727 USA 728 730 Appendix A 732 Default fields and suggested lengths connected to different object 733 types. 735 All entries: Information common to all entries 736 type 64 737 name 256 738 address 128 739 proxy 32 740 password 32 742 type=phone: Information found in a phonebook 743 phone 64 744 fax 64 746 type=person: Information about a human being 747 alias 32 748 forename 64 749 surname 64 750 group 32 751 email 128 752 public_key 4096 753 nickname 128 754 www 256 755 acl 128 757 type=staff: Information about an employee 758 empno 16 759 department 64 760 supervisor 64 761 secretary 64 762 office_location 128 763 office_address 128 764 office_phone 64 765 title 64 766 pager 64 767 hours 128 769 type=unit: Information about an organizational unit 770 email 128 771 www 256 772 public_key 4096 774 Appendix B 776 Result codes 778 100 In progress (general). 779 101 Echo of current command. 780 102 Count of number of matches to query. 781 103 No hostname found for IP address. 782 200 Success (general). 783 201 Database ready, but read-only. 784 300 More information (general). 785 301 Encrypt this string. 786 302 Print this prompt. 787 400 Temporary error (general). 788 401 Internal database error. 789 402 Lock not obtained within timeout period. 790 403 Login would have been OK, but database read-only 791 475 Database unavailable; try later. 792 500 Permanent error (general). 793 501 No matches to query. 794 502 Too many matches to query. 795 503 Not authorized for requested information. 796 504 Not authorized for requested search criteria. 797 505 Not authorized to change requested field. 798 506 Request refused; must be logged in to execute. 799 507 Field does not exist. 800 508 Field is not present in requested entry. 801 509 Alias already in use. 802 510 Not authorized to change this entry. 803 511 Not authorized to add entries. 804 512 Illegal value. 805 513 Unknown option. 806 514 Unknown command. 807 515 No indexed field in query. 808 516 No authorization for request. 809 517 Operation failed because database is read-only. 810 518 To many entries selected by change command. 811 520 CPU usage limit exceeded. 812 521 Change command would have overridden existing field, 813 and the "addonly" option is on. 814 522 Attempt to view "Encrypted" field. 815 523 Expecting "answer" or "clear". 816 524 Names of help topics may not contain "/". 817 525 Email authentication failed 818 526 Host name address not found in DNS 819 527 Reverse DNS lookup does not match forward DNS lookup 820 528 General Kerberos database error. 821 529 Selected authentication method not available 822 590 Remote queries not allowed. 823 598 Command unknown. 824 599 Syntax error. 825 600 Ambiguous or multiple match 827 Appendix C 829 Description of the client command language using the augmented 830 Backus-Naur Form (RFC822). 832 response = code [index] [field] text CRLF 834 code = [-] LDIG 2DIGIT ":" 835 index = number ":" 836 field = 1*SPACE attribute ":" 1*SPACE 837 text = 1*( CHAR / LWSP-char ) 839 command = ph-command CRLF 841 ph-command = "status" / a-command / oa-command 842 ph-command =/ av-command / answer-command / query-command 843 ph-command =/ delete-command / change-command / "help" / quit-command 845 a-command = ("siteinfo"/"fields"/"id"/"login"/"help"/"email"/ 846 "clear") [attribute] 847 oa-command = ("xlogin") number attribute 848 av-command = ("set"/"add"/"make") 1*attribute-value 849 answer-command = ("answer") 1*printable 850 query-command = ("query"/"ph") 1*selection ["return" 1*attribute] 851 quit-command = "quit" / "exit" / "stop" 852 change-command = "change" 1*selection make 1*attribute-value 853 delete-command = "delete" selection 855 selection = value / attribute-value 857 attribute-value = attribute "=" value 859 value = 1*(cstring / quoted-string / set) 861 cstring = 1*( ALPHA / DIGIT / S_SPEC / set / quoted-pair ) 862 attribute = 1*( ALPHA / DIGIT / "_" / "-" ) 863 number = 1*(DIGIT) 865 quoted-string = <"> 1*(qtext/quoted-pair) <"> 867 quoted-pair = "\" CHAR 868 qtext = 1*( CHAR / CR / SPEC1 / DELIMIT1 / DELIMIT2 / LWS ) 869 set = '[' 1*(ALPHA/DIGIT) ']' 871 LWSP-char = SPACE / HTAB 872 LWS = 1*([CRLF] (LWSP-char)) 873 CRLF = CR LF 874 S_SPEC = '*'/'+'/'?' 875 SPEC1 = "=" / "*" / "?" / "+" / "[" / "]" 876 SPEC2 = "\" / """ 877 DELIMIT1 = SPACE / HTAB / LF 878 DELIMIT2 = "," / ";" / ":" 879 PRINTABLE = %d32..%d126 880 CTL = %d0..%d31 / %d127..%d160 881 ASCII = DIGIT / ALPHA / OTHER 882 ALPHA = %d65..%d90 / %d97..%d122 883 DIGIT = %d48..%d57 884 LDIG = %d49..%d54 885 SPACE = %d32 886 SEP = (CR LF) / LF 887 CR = %d13 888 LF = %d10 889 HTAB = %d9 890 CHAR = %d33..%d126 / %d160..%d255 891 OTHER = "(" / ")" / "-" / "." / "/" 892 "@" / "$" / "_" / "!" / "~" / 893 "'" / "#" / "&" / "<" / ">" / 894 "^" / "`" / "{" / "|" / "}"