File: rfc2378.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1235 lines) | stat: -rw-r--r-- 38,960 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235






Network Working Group                                       R. Hedberg
Request for Comments: 2378                             Umea University
Category: Informational                                       P. Pomes
                                                        QUALCOMM, Inc.
                                                        September 1998


                 The CCSO Nameserver (Ph) Architecture

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   The Ph Nameserver from the Computing and Communications Services
   Office (CCSO), University of Illinois at Urbana-Champaign has for
   some time now been used by several organizations as their choice of
   publicly available database for information about people as well as
   other things.  This document provides a formal definition of the
   client-server protocol.  The Ph service as specified in this document
   is built around an information model, a client command language and
   the server responses.

1.  Overview

1.1.  Basic Information Model

   At its simplest the Ph database can be thought of as a computer-
   resident "phone book".  However, it can be used to collect arbitrary
   information about people, and in response to a query about an object
   named in the database, return information about that entity.  It is
   in short a nameserver for people and objects.  It was designed to
   keep a relatively small amount of arbitrary information about a
   relatively large number of people or things, and provide access to
   that information over the Internet.  In order to structure the
   information the manager of the database has to decide which views to
   present of the real-world objects that are to be represented in the
   database.  Each view is then composed of a number of fields and their
   values.  To support this concept Ph has the notion of named
   information, i.e., categorizing information into what are called
   fields and assigning descriptive names to those fields.



Hedberg & Pomes              Informational                      [Page 1]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   Even if the database resides and is reachable from the Internet it is
   local in the meaning that no server is supposed to be able to refer a
   client to another server which might hold the wanted information.
   However a server may contain a list of other Nameservers which can be
   used by clients to query other Nameservers for information.

1.1.1.  Fields

   A field descriptor is associated with each field and is used to
   describe the type and behavior of the field.  A field descriptor
   includes the fieldname, the maximum length of information the field
   can store before truncation, keywords describing the properties of
   the field as well as free text describing what kind of information
   the field is supposed to hold.

   The keywords can be any of the following:

   Always:   Forces the field's contents to be always printed in
             addition to whatever fields specified by the query.

   Any:      This field is always searched by queries. To be most
             use ful, a field marked as Any should also have the Indexed
             and Lookup keywords as well.

   Change:   Can be changed by the owner of the entry.

   Default:  Printed if no return clause is given in the query.

   Encrypt:  Must be encrypted before transmission.

   ForcePub: Viewable/searchable regardless of the content of the
             suppress field

   Indexed:  Fields that are kept track of in the database's index for
             efficient lookups.  At least one indexed field must be
             present in each query.

   LocalPub: May be viewed by anyone in the "local" domain or address
             space.  Fields with this keyword are completely invisible
             outside of the "local" domain.  They will not be shown with
             the fields command (section 3.3), and are disallowed in
             query commands or return clauses (section 3.8).

   Lookup:   May be used in the selection part of a query.  A Field
             without this keyword may not be used to select entries.

   NoMeta:   Wildcard searches are disallowed.




Hedberg & Pomes              Informational                      [Page 2]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   NoPeople: No entry of type "person" may include this field.

   Private:  Field may be viewed by Heros (section 1.4) only.

   Public:   May be viewed by anyone.  Fields not marked with this
             keyword may only be viewed by the entry's owner or a Hero.

   Sacred:   Changes to the field are prohibited except via non-network
             invocations of the server, i.e., from a tty, file, or pipe.

   Turn:     Users may turn off visibility of a field to everyone except
             themselves and Heros by prefixing the field text with '*'.

   Unique:   Any change to the field will be rejected if the change
             causes the modified field to match the same field in any
             other entry.

1.1.2.  Character Sets

   Historically Ph has been restricted to only handle printable
   characters, that is characters with hexadecimal values between 0x20
   and 0x7f.  Lately with the spreading of 8-bit clean Operating Systems
   there is no reason to keep this limitation.

   This document therefore proposes that ISO-8859-1 shall be regarded as
   an alternative character set for Ph, the default still being US-
   ASCII.

   Clients that utilize ISO-8859-1 should request that the server return
   ISO-8859-1 by using the "set"-command.

   In the instance that values are stored using ISO-8859-1 and are to be
   shown to a client expecting US-ASCII, the characters with character
   codes outside of the US-ASCII range should be displayed in the
   "Quoted-Printable" content-transfer-encoding form defined in RFC-2045
   [MIME].

   1.2.  Standardization issues

   Each Nameserver manager is in essence free to name new fields to suit
   the special needs of his/her organization.  But in order to make the
   directory service useful outside of the organization it is
   recommended that a core set of standard fields always should be
   present.

   Therefore this document defines a couple of standard collections of
   fields (Appendix A).




Hedberg & Pomes              Informational                      [Page 3]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   Also note that the architecture makes no assumption about the search
   and retrieval mechanisms used within individual servers.  Operators
   are thereby free to use any kind of dedicated databases, fast
   indexing software or even gateways to other directory services to
   store and retrieve the information, if desired.

   Ph simply functions as a known front-end, offering a simple data
   model in addition to a well known port and simple query language.

1.3.  Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

1.4.  Heros

   For Ph a Hero is equivalent to a superuser or operator.  Being in
   Hero mode means that some or all artificial limits are removed; full
   Heros may change any field in any entry in the database, as well as
   view as many entries as they wish.  Heros can also be limited to one
   field of one other entry.  Hero mode is used mostly for
   administrative purposes, delegation of group authority over selected
   fields, and is controlled by the acl field.

2.  Basic Operation

   Initially, the server host starts the Ph service by listening on TCP
   port 105.  When a client host wishes to make use of the service, it
   establishes a TCP connection to the server host.  The client and the
   Ph server then exchange commands and responses (respectively) until
   the connection is closed or aborted.

2.1.  Command syntax

   Commands in Ph consist of a keyword optionally followed by zero or
   more keywords or values, separated by spaces, tabs or newlines, and
   followed by a carriage return-linefeed (CRLF) pair. A more thorough
   description using BNF is given in Appendix C.

   Values containing spaces, tabs or newlines must be enclosed in double
   quotes ('"').  In addition the sequences "\n", "\t","\"" and "\\" may
   be used to mean newline, tab, double quote and backslash,
   respectively.

   Keywords must be given in lower case; case in the values of fields is
   preserved, although queries are not case-sensitive.





Hedberg & Pomes              Informational                      [Page 4]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


2.2.  Response syntax

   Responses consist of a result code followed by additional information
   possibly separated by entry index and/or field name and are
   terminated by a CRLF pair.

      result code:[entry index:][field name:]text

   Responses to some commands might be multi-lined.  In these cases each
   line in the response, except the last, has the appropriate result
   code negated (prefaced with "-").  The last line then starts with the
   appropriate result code without negation.  Each line must be
   terminated by a CRLF pair.

   If a particular command can apply to more than one entry, then the
   multilined response must be so organized that all information
   pertaining to each entry is returned on consecutive lines, and that
   each of those lines must have one and the same entry index directly
   following the resultcode.  The first entry index should be 1 and
   incremented each time a new entry is referred to.

      C: query hedberg return email name title
      S: 102:There were 3 matches to your request.
      S: -200:1:        email: canheg95@student.umu.se
      S: -200:1:         name: Carl Johan Hedberg
      S: -200:1:        title: Student
      S: -200:2:        email: parheg95@student.umu.se
      S: -200:2:         name: Par Hedberg
      S: -200:2:        title: Student
      S: -200:3:        email: Roland.Hedberg@umdac.umu.se
      S: -200:3:         name: Roland Hedberg
      S: -200:3:        title: Boss of the Network group
      S: 200:Ok

   Commands that can apply to more than one field must have the name of
   the field to which the response applies directly following the entry
   index.

   The text of the response will be either an error message in human
   readable format, or data from the Nameserver.  Whitespace (spaces or
   tabs) may appear anywhere in the response, but the field name and
   text columns if present must each begin with a whitespace character.

   Since more than one specific piece of information may be manipulated
   by a particular command, it is possible for parts of a command to
   succeed, while other parts of the same command fail.  This situation
   is handled as a single multi-line response with the result code
   changing as appropriate.



Hedberg & Pomes              Informational                      [Page 5]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   As for FTP, the result codes are in the range 100-699 (or from -699
   to -100 for multiline responses), where the leading digit has the
   following significance:

      1: In progress
      2: Success
      3: More information needed
      4: Temporary failure; it may be worthwhile to try again.
      5: Permanent failure
      6: Phquery specific codes

   Many commands generate more than one line of response; every client
   should be prepared to deal with such continued responses.  Note that
   a command is finished when and only when the result code on a
   response line (treated as a signed integer) is greater than or equal
   to 200.

   Clients should assume that any numeric response, within the above
   mentioned ranges, are valid.  Also note that the server is allowed to
   send one or more lines with result codes between -199 - -100 (the
   leading "-" indicates a continuation line) and 100 - 199, as status
   information, before the actual results are transmitted.

2.3.  Format of a search string

   Matching is not sensitive to upper or lower case letters and is
   normally done on a word-by-word basis. That is, both the query
   expression and the entry information is broken up into words, and
   individual words are compared using exact matching.  If the order of
   the words is important in a query, then the query string can be
   surrounded by '"' (double quotes), whereby the complete search string
   is matched against the information in the Nameserver database.

   Word delimiters are the following characters: <SPACE>, <TAB>, <NEW-
   LINE>, ",", ";" and ":" .  These characters are not indexed and
   should not be part of the search string.

   However, special symbols, called "wildcard" characters, can be used
   if the exact spelling is unknown.  The '*' (asterisk, 0x2A) is used
   in place of zero or more characters, '+' (plus, 0x2B) in place of one
   or more unknown characters, and '?' (question mark, 0x3F) can be used
   when exactly one character is unknown.  If the unknown character can
   be one of a limited set this can be specified by surrounding the set
   with brackets, e.g., [ei] means that in that place an 'e' or an 'i'
   would match.






Hedberg & Pomes              Informational                      [Page 6]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


3.  Commands

3.1.  status

   status

   Prints the message of the day and the current status of the
   nameserver.

      C: status
      S: 100:Qi server $Revision: 1.6 $
      S: 100:Ph passwords may be obtained at CCSO Accounting,
      S: 100:1420 Digital Computer Lab, between 8:30 and 5 Monday-Friday.
      S: 100:Be sure to bring your U of I ID card.
      S: 200:Database ready

3.2.  siteinfo

   siteinfo

   Returns information about the servers site. Possible fields are

   Version        Version information for the server.
   Maildomain     The mail domain to use for phquery-type mail.
   Mailfield      The field containing the specific email address.
   Mailbox        Mandatory entry that names the field to use as
                  maildrop.
   Administrator  Guru in charge of service.
   Passwords      Person in charge of ordinary password/change requests.
   Authenticate   Authentication methods supported by the server,
                  ordered in the site-preferred way.  Presently the
                  following options are defined:

                    1   attempt auto login
                    2   allowed to be interactive if needed
                    4   use ANSI X9.9 challenge/response
                    8   use v4 Kerberos login
                    16  use v5 Kerberos [KRB5] login
                    32  use GSS-API [GSS-API] login
                    64  use email login
                    128 password encrypted response to challenge
                    256 use clear-text password
                    512 use HMAC [HMAC] with SHA-1 of challenge string








Hedberg & Pomes              Informational                      [Page 7]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   Example

        C: siteinfo
        S: -200:1:version:3.1
        S: -200:2:maildomain:umu.se
        S: -200:3:mailfield:alias
        S: -200:4:mailbox:email
        S: -200:5:administrator:roland.hedberg@umdac.umu.se
        S: -200:6:passwords:roland.hedberg@umdac.umu.se
        S: -200:7:authenticate:64:32:128
        S: 200: Ok.

   The mail fields in the siteinfo command direct how address
   information stored in the Nameserver is to be used for delivering
   mail.

   The specific (username, host) pair to where a user's mail should be
   sent for final delivery is stored in the field named by {mailbox}.
   Phquery and like utilities will use this field.

   To construct a useable email address from Nameserver information, the
   algorithm below is followed:

        if ({maildomain} is not null) then
             address = (contents of {mailfield})@{maildomain}
        else
             address = (contents of {mailfield})

   Some existing client software will not format email addresses
   correctly if the value of {mailbox} is set to anything other than
   "email" when {maildomain} is non-empty.

   If {mailbox} is set to anything other than {email}, {maildomain} must
   be reported empty by the siteinfo command.  Also reformatting of each
   record's {mailfield} must be done by the server before reporting it
   to the client.

3.3.  fields

   fields [field ...]

   Without an argument, a list of all available field descriptors should
   be delivered.  Any space-separated argument(s) restricts the list to
   the named fields.  Fields marked with the "LocalPub" keyword (section
   1.1.1) should not be delivered outside of the local domain.






Hedberg & Pomes              Informational                      [Page 8]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   The output of the command consists of two lines describing each
   field.  The first line defines the field in technical terms (max
   length and field attributes), while the second line is a brief
   description of what the field is intended to    hold.  The second
   number of each response is the field id number.

      C: fields
      S: -200:6:alias:max 32 Indexed Lookup Public Default
      S: -200:6:alias:Unique name for user.
      S: -200:3:name:max 64 Indexed Lookup Public Default
      S: -200:3:name:Fullname
      S: -200:2:email:max 128 Lookup Public Default
      S: -200:2:email:Account to receive electronic mail.
      S: -200:16:other:max 256 Lookup Public Default Change
      S: -200:16:other:Other info the user finds important.
      S: -200:33:home_phone:max 60 Lookup Public Change Turn
      S: -200:33:home_phone:Home telephone number.
      S: 200:Ok.

3.4.  id

   id information

   Enters the given information in the Nameserver's log.  This command
   is used by the Ph client to enter the user id of the person running
   it.

3.5.  set

   set [option[=value] ...]

   Sets the named option for this nameserver session to a value.  The
   default string "on" is used if no value is supplied.  Used without
   arguments it return the settable options and their current value.
   Some common options are

   echo      If on, echo the client's commands back to the client.
   limit     Changes that affect more than the specified number of
                entries results in an error.
   charset   Return responses to the client in the character set
                specified.
   verbose   If on, report interim progress messages to the client.
   addonly   If on, change commands can only create fields in entries,
                not modify them.
   nolog     If on, disable logging.
   external  If on, make Fields marked as "LocalPub" invisible.





Hedberg & Pomes              Informational                      [Page 9]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   Example

      C: set verbose=off
      S: 200:Done.

      C: set
      S: -200:echo:off
      S: -200:limit:2
      S: -200:charset:iso-8859-1
      S: -200:verbose:off
      S: -200:addonly:off
      S: -200:nolog:off
      S: -200:external:on
      S: 200:Done.

3.6.  login, logout, answer, clear, email, and xlogin

3.6.1.  login

   login [alias]

   The "login" command allows client users to identify themselves to the
   Nameserver. More specifically it identifies a client user with a
   particular entry in the Nameserver and allows them to change fields
   in that entry and possibly other entries.  It is also necessary to be
   logged in to the Nameserver to view certain sensitive fields in the
   user's own entry.

   In order to use the "login" command the client must prompt the user
   for their ph alias and password.  The client is then responsible for
   (optionally) encrypting the password and sending it to the server.
   This will be covered in sections 3.6.3 (answer) and 3.6.4 (clear).

      C: login foo
      S: 301:,:P"_Y$ONU%"SDUQ6&^`ZZ'?*#Y`A_.Z/A>?@SH>*-

3.6.2.  logout

   logout

   The "logout" command allows a user who is logged in to the Nameserver
   to logout.

      C: logout S: 200:Ok.







Hedberg & Pomes              Informational                     [Page 10]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


3.6.3.  answer

   answer encrypted-response

   In response to the login command, the Nameserver responds with a
   random challenge string.  The Nameserver client encrypts the
   challenge with the password supplied by the user, uuencodes the
   result into US-ASCII, and returns the printable result in the
   "answer" command:

   C: login ppomes
   S: 301:.%$&.D^67$*1?<.2S@DR:Z@M*)AV-<:4QM>#R>M*HT
   C: answer M5K'F:NI(a?M?O2+-a9`48RA#ZF=L9)G)/XRS7Q^0>0@-R7X$WGb`50B]
   S: 200:ppomes:Hi how are you?

   The encryption algorithm is based on a three rotor Enigma engine.
   There are known attacks on the security of this approach.

   The answer command is also used to return method-specific responses
   to the xlogin command (section 3.6.6).

3.6.4.  clear

   clear cleartext-password

   The "clear" command can be used instead of the "answer" command to
   complete a login sequence.  It's argument is the user's cleartext
   password.  This command is supplied only to support those clients
   that have not implemented one of the encryption engines used by the
   "answer" command.  It's use is strongly discouraged.

      C: login ppomes
      S: 301:E=@Y&VW^_9YVI;D5.[EB0:B)9Z#_&X$:2)/eL$VJC87
      C: clear MySecret
      S: 200:ppomes:Hi how are you?

3.6.5.  email

   email local-userid

   The "email" command can also be used instead of the "answer" command
   to complete a login sequence.  The value of local-userid is the
   user's login name on the local machine.  If all of the following
   conditions are true, then the email command will be accepted by the
   server:






Hedberg & Pomes              Informational                     [Page 11]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   1) The connection to the server originates on port 1023 or less on
      the client.  Note: This is a system port.  Port 1023 is not
      allocated to this use.

   2) The canonical name of the client's host matches the right-hand
      side of the email address of the requested alias specified in the
      "login" command.

   3) The "local-userid" matches the left-hand side of the email
      address belonging to the requested alias.

   This is a weak but convenient form of authentication.  Depending on
   the information users are allowed to change about themselves and the
   threat environment the server operates in, this method may be
   appropriate.  Servers should take care to avoid DNS spoofing.

3.6.6.  xlogin

   xlogin option alias

   Extended login command for GSS, Kerberos v4 and v5, ANSI X9.9 token
   devices (e.g., SNK/4), etc. The option is one of the values returned
   in the Authenticate field of the "siteinfo" command (section 3.2).
   Alias is the user's alias.

      C: xlogin 16 ppomes
      S: 301:DoKrbLogin started; send Kerberos mutual authenticator.
      C: answer MJa8QO1cJHYz2IdWyg7uhAnixVqgCZQBWr64ciXYku1ktdu....
      S: 200:ppomes:Hi how are you?

      C: xlogin 4 ppomes
      S: 302:SNK Challenge "024142":
      C: answer 82344338
      S: 200:ppomes:Hi how are you?

   The answer command returns the requested quantity, Kerberos
   authenticator, X9.9 device response, etc.  Binary quantities are
   first uuencoded into US-ASCII.

3.7.  add

   add field=value...

   This command is used to add new entries to the database.  You must be
   logged in and have full Hero privileges (section 1.4) to use "add".

      C: add name="doe john" id="123456789" alias="j-doe"
      S: 200:Ok.



Hedberg & Pomes              Informational                     [Page 12]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


3.8.  query

   query [field=]value [field=value] . . . [return field1 [field2]]

   If no field is specified together with a value then the field is
   assumed to be "name" and/or "nickname".  When more than one field-
   value specification are given in a query, entries matching all
   specifications are returned (implicit AND).

   It is possible to define which fields should be returned by adding a
   "return" clause.  If no return clause is defined the Ph server will
   return a default list of fields.  Typical default fields are "alias",
   "name", "title", "email", "phone", "address", "department", "www",
   and "other".  A return clause consists of the word "return" followed
   by a list of fields or the word "all".  If the word "all" is used
   then all viewable fields will be returned.

      C: query name=doe name=john
      S: 102:There was 1 match to your request.
      S: -200:1:            alias: j-doe
      S: -200:1:             name: doe john
      S: 200:Ok.

3.9.  delete

   delete [field=]value...

   This command is used to delete entire entries from the database.  You
   must be logged in and have full Hero (section 1.4) privileges to use
   "delete".

   The arguments to the "delete" command are the same as the selection
   part of a "query" command.  "Delete" finds all the entries that match
   the argument(s) and deletes them.

   The "delete" command obeys the Nameserver "limit" option, which can
   be used to prevent deletion of more entries than intended.

      C: delete name="doe john" id="123456789" alias="j-doe"
      S: 200:1 entries deleted.

3.10.  change

   change [field=]value    [make|force] field="value"...

   This command is used to change one or more fields in one or more
   entries to the values specified.  The "change" command consists of
   two clauses, the "change" clause and the "make" or "force" clause.



Hedberg & Pomes              Informational                     [Page 13]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   The "change" clause determines which entries will be affected by the
   command.  It uses the same arguments as the selection clause of a
   "query" command.  The "make" or "force" clause specifies which
   field(s) will be changed and the new value(s) of the specified
   field(s).  The "force" clause is only used to make non-encrypted
   changes to fields marked "Encrypt".

   You must be logged in to use "change".

   The "change" command obeys the Nameserver "limit" option, which can
   be used to prevent changing the field contents of more entries than
   intended.

      C: change alias=j-doe force password=NewSecret
      S: 200:1 entry changed.

      C: set limit=500
      S: 200:Done.
      C: change fax="(619) 555-1212" make fax="(760) 555-1212"
      S: 200: 113 entries changed.

3.11.  help

   help    [{native|client} [topic ...]]

   Prints help on the Nameserver or on specific clients.  If client is
   specified, it should be a valid Nameserver client identifier, such as
   "ph".  The client-specific help will first be searched for topic, and
   then the native help will be searched.  If topic is omitted, a list
   of all available help texts will be returned.  If "native" or client
   are also omitted, a list of clients will be returned.

C: help native 101
-200:1:101:
-200:1: The Nameserver echo option is set.  The text of this response is
-200:1: the command you just gave, which has not (yet) been executed.
200:Ok.

3.12.  quit/exit/stop

   quit

   Terminates the session with the Nameserver and causes the client to
   exit.

      C: quit
      S: 200:Bye!




Hedberg & Pomes              Informational                     [Page 14]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


4.  Security

4.1.  Transport Layer

   In the absence of encryption between client and server, all
   Nameserver traffic is unsecure.  Kerberos v4, v5, and the GSS-API all
   provide encryption mechanisms, however the Nameserver protocol does
   not support the means to negotiate encryption between client and
   server.  This implies that all traffic can be seen by other machines
   having access to the network linking the client and server.
   Furthermore clear-text traffic is subject to modification in transit
   between client and server.  Possible ways of augmenting this would be
   to use something like TLS [TLS] or IPSec [IPSEC].

4.2.  Server Authentication

   Unless one of the mutual authentication mechanisms is used, e.g.,
   Kerberos 4/5 or GSS-API, there is no way to prove the identity of a
   server.  Further, there is no mechanism to prove a given server is
   authoritative for a set of information.

4.3.  Secure User Authentication

   The Ph protocol allows the negotiation of several authentication
   protocols between client and server, some weak and some strong.  It
   does not prohibit the use of cleartext passwords, something which
   should be depreciated, but is useful when dealing with some clients.

4.4.  Privacy and Access Lists

   Directory services like the CCSO white pages server that contain
   information on persons have to consider privacy issues.  This paper
   describes one way of partitioning specific attributes from unwanted
   access by designating them visible only to the "local" community,
   visible only to the person connected with the information, or visible
   only to the database administrator.















Hedberg & Pomes              Informational                     [Page 15]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


4.5.  References

   [GSS-API] Linn, J., "Generic Security Service Application Program
             Interface, Version 2", RFC 2078, January 1997.

   [HMAC]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
             Hashing for Message Authentication", RFC 2104, February
             1997.

   [IPSEC]   Atkinson, R., "Security Architecture for the Internet
             Protocol", RFC 1825, August 1995.

   [KRB5]    Kohl, J., and C. Neuman, "The Kerberos Network
             Authentication Service (V5)", RFC 1510, September 1993.

   [TLS]     Dierks, T., and C. Allen, "The TLS Protocol,
             Version 1.0", Work in Progress.

   [MIME]    Freed, N., and N. Borenstein, "Multipurpose Internet Mail
             Extensions, (MIME) Part One: Format of Internet Message
             Bodies", RFC 2045, November 1996.

5.  Miscellaneous

5.1.  Authors' Addresses

   Roland Hedberg
   Umdac
   Umea University
   901 87 Umea
   Sweden

   EMail: Roland.Hedberg@umdac.umu.se


   Paul Pomes
   Qualcomm Inc
   6455 Lusk Blvd
   San Diego, CA
   USA

   EMail: ppomes@qualcomm.com









Hedberg & Pomes              Informational                     [Page 16]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


Appendix A

   Default fields and suggested lengths connected to different object
   types.

   All entries:  Information common to all entries
   type              64
   name              256
   address           128
   proxy             32
   password          32

   type=phone:   Information found in a phonebook
   phone             64
   fax               64

   type=person:  Information about a human being
   alias             32
   forename          64
   surname           64
   group             32
   email             128
   public_key        4096
   nickname          128
   www               256
   acl               128

   type=staff:   Information about an employee
   empno             16
   department        64
   supervisor        64
   secretary         64
   office_location   128
   office_address    128
   office_phone      64
   title             64
   pager             64
   hours             128

   type=unit:   Information about an organizational unit
   email             128
   www               256
   public_key        4096








Hedberg & Pomes              Informational                     [Page 17]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


Appendix B

   Result codes

   100 In progress (general).
   101 Echo of current command.
   102 Count of number of matches to query.
   103 No hostname found for IP address.
   200 Success (general).
   201 Database ready, but read-only.
   300 More information (general).
   301 Encrypt this string.
   302 Print this prompt.
   400 Temporary error (general).
   401 Internal database error.
   402 Lock not obtained within timeout period.
   403 Login would have been OK, but database read-only
   475 Database unavailable; try later.
   500 Permanent error (general).
   501 No matches to query.
   502 Too many matches to query.
   503 Not authorized for requested information.
   504 Not authorized for requested search criteria.
   505 Not authorized to change requested field.
   506 Request refused; must be logged in to execute.
   507 Field does not exist.
   508 Field is not present in requested entry.
   509 Alias already in use.
   510 Not authorized to change this entry.
   511 Not authorized to add entries.
   512 Illegal value.
   513 Unknown option.
   514 Unknown command.
   515 No indexed field in query.
   516 No authorization for request.
   517 Operation failed because database is read-only.
   518 To many entries selected by change command.
   520 CPU usage limit exceeded.
   521 Change command would have overridden existing field,
   and the "addonly" option is on.
   522 Attempt to view "Encrypted" field.
   523 Expecting "answer" or "clear".
   524 Names of help topics may not contain "/".
   525 Email authentication failed
   526 Host name address not found in DNS
   527 Reverse DNS lookup does not match forward DNS lookup
   528 General Kerberos database error.
   529 Selected authentication method not available



Hedberg & Pomes              Informational                     [Page 18]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   590 Remote queries not allowed.
   598 Command unknown.
   599 Syntax error.
   600 Ambiguous or multiple match















































Hedberg & Pomes              Informational                     [Page 19]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


Appendix  C

   Description of the client command language using the augmented
   Backus-Naur Form (RFC822).

   response = code [index] [field] text CRLF

   code     = [-] LDIG 2DIGIT ":"
   index    = number ":"
   field    = 1*SPACE attribute ":" 1*SPACE
   text     = 1*( CHAR / LWSP-char )


   command     = ph-command CRLF

   ph-command  =  "status" / a-command / oa-command
   ph-command  =/ av-command / answer-command / query-command
   ph-command  =/ delete-command / change-command / "help" / quit-command

   a-command       = ("siteinfo"/"fields"/"id"/"login"/"help"/"email"/
              "clear") [attribute]
   oa-command      = ("xlogin") number attribute
   av-command      = ("set"/"add"/"make") 1*attribute-value
   answer-command  = ("answer") 1*printable
   query-command   = ("query"/"ph") 1*selection ["return" 1*attribute]
   quit-command    = "quit" / "exit" / "stop"
   change-command  = "change" 1*selection make 1*attribute-value
   delete-command  = "delete" selection

   selection       = value / attribute-value

   attribute-value = attribute "=" value

   value           = 1*(cstring / quoted-string / set)

   cstring         = 1*( ALPHA / DIGIT / S_SPEC / set / quoted-pair )
   attribute       = 1*( ALPHA / DIGIT / "_" / "-" )
   number          = 1*(DIGIT)

   quoted-string   = <"> 1*(qtext/quoted-pair) <">

   quoted-pair  =  "\" CHAR
   qtext        = 1*( CHAR / CR / SPEC1 / DELIMIT1 / DELIMIT2 / LWS )
   set          = '[' 1*(ALPHA/DIGIT) ']'

   LWSP-char    = SPACE / HTAB
   LWS          = 1*([CRLF] (LWSP-char))
   CRLF         = CR LF



Hedberg & Pomes              Informational                     [Page 20]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


   S_SPEC       = '*'/'+'/'?'
   SPEC1        = "=" / "*" / "?" / "+" / "[" / "]"
   SPEC2        = "\" / """
   DELIMIT1     = SPACE / HTAB / LF
   DELIMIT2     = "," / ";" / ":"
   PRINTABLE    = %d32..%d126
   CTL          = %d0..%d31 / %d127..%d160
   ALPHA        = %d65..%d90 / %d97..%d122
   DIGIT        = %d48..%d57
   LDIG         = %d49..%d54
   SPACE        = %d32
   SEP          = (CR LF) / LF
   CR           = %d13
   LF           = %d10
   HTAB         = %d9
   CHAR         = %d33..%d126 / %d160..%d255
   OTHER        = "(" / ")" / "-" / "." / "/"
          "@" / "$" / "_" / "!" / "~" /
          "'" / "#" / "&" / "<" / ">" /
          "^" / "`" / "{" / "|" / "}"































Hedberg & Pomes              Informational                     [Page 21]

RFC 2378         The CCSO Nameserver (Ph) Architecture    September 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Hedberg & Pomes              Informational                     [Page 22]