rfc2378.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/3 页

   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="[phone]" make fax="[phone]"
      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,