home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ids-ph-03.txt
< prev
next >
Wrap
Text File
|
1997-05-07
|
33KB
|
1,066 lines
IDS Working Group Roland Hedberg
INTERNET-DRAFT Umea University
Paul Pomes
QUALCOMM, Inc
The CCSO Nameserver (Ph) Architecture
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
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. It is now widely felt that the Internet community
would benefit from having a more rigorous definition of the client-
server protocol, this document will hopefully achieve that goal. The
Ph service as specified in this document is built around an informa-
tion 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 or things, and in response to a query about
[Page 1]
INTERNET DRAFT May 1997
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
he wants 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; that is categorizing information into
what are called fields and assigning descriptive names to those
fields.
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 the field, keywords
describing the properties of the field as well as free text describ-
ing what kind of information the field is supposed to hold.
The keywords can be one of the following:
Always: Forces the field's contents to be always printed in addi-
tion to whatever fields specified by the query.
Any: This field is always searched by queries. To most useful,
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 marked Indexed are kept track of in the database's
index for efficient lookups. At least one indexed field
must be present in each query.
[Page 2]
INTERNET DRAFT May 1997
LocalPub: May be viewed by anyone in the "local" domain or address
space. Fields with the LocalPub property are completely
invisible outside of the "local" domain and will not be
shown with the fields command (section 3.4), is disallowed
in query/ph commands (section 3.9), and can not be used in
return clauses (section 3.10) for anyone outside of the
"local" domain.
Lookup: May be used in the selection part of a query; a field not
marked Lookup may not be used to select entries.
NoMeta: Wildcard searches are disallowed.
NoPeople: No entry of type "person" may include this field.
Private: Field may be viewed by heros only.
Public: May be viewed by anyone, fields not marked public 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
himself and heros by prefixing the field text with '*'.
Unique Any change to the field will be rejected if the change
causes the field to match the same field in any other
entry.
1.1.2. Character Sets
Historically Ph has been restricted to only handle printable charac-
ters, 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.
If a client can handle ISO-8859-1 it should request the server to
return ISO-8859-1 by using the "set"-command.
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
[Page 3]
INTERNET DRAFT May 1997
directory service useful even 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).
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 index-
ing software or even gateways to other directory services to store
and retrieve the information, if desired.
The Ph simply functions as a known front-end, offering a simple data
model as well as 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 he wishes. Heros can also be limited to one
field of one other entry. Hero mode is used mostly for administra-
tive 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 exchanges 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
[Page 4]
INTERNET DRAFT May 1997
be used to mean newline, tab, double quote and backslash, respec-
tively.
Keywords must be given in lower case; case in the values of fields is
preserved, although queries are not case-sensitive.
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 ter-
minated by a CRLF pair.
result code:[entry index:][field name:]text
Responses to some commands might be multi-lined. In these cases each
line, except the last, in the response 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 per-
taining to one entry is return on consecutive lines, and that all
those lines must have one and the same entry index directly following
the resultcode. The first entry index should be 1, and be incre-
mented each time a new entry is being 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 intended for
human consumption, 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.
[Page 5]
INTERNET DRAFT May 1997
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.
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 not make any assumptions as to which numeric
responses, within the above mentioned ranges that are valid. Also
note that the server is allowed to send one or more lines with
resultcodes between -199 - -100 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 nor-
mally done on a word-by-word basis. That is, both the query expres-
sion and the entry information is broken up into words, and indivi-
dual words are compared using exact matching. If the order of the
words are important in a query, then the query string can be sur-
rounded by '"', 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, 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
[Page 6]
INTERNET DRAFT May 1997
surrounding the set with brackets, e.g., [ei] means that in that
place a 'e' or a 'i' would match.
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: 3.1 $
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
siteonfo
Returns information about the servers site.
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 mail-
drop.
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 fol-
lowing 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 login
32 use GSS-API login
64 use email login
[Page 7]
INTERNET DRAFT May 1997
128 password encrypted response to challenge
256 use clear-text password
512 use HMAC (RFC-2104) with SHA-1 of challenge string
C: siteinfo
S: -200:1:version:3.1
S: -200:1:maildomain:umu.se
S: -200:2:mailfield:alias
S: -200:3:mailbox:email
S: -200:4:administrator:roland.hedberg@umdac.umu.se
S: -200:5:passwords:roland.hedberg@umdac.umu.se
S: -200:6:authenticate:64:32:128
S: 200: Ok.
The mail fields in the siteinfo command direct how address informa-
tion 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})
N.B., Changing the value of {mailbox} to anything other than "email"
should not be done if {maildomain} is non-empty because extant refor-
matting clients will not do the right thing. That is, if {mailbox}
is something other than "email", empty {maildomain} and do the
address reformatting on the server.
3.3. fields
fields [field ...]
Without an argument, a list of all available field descriptors should
be delivered. Fields marked with the "LocalPub" property (Section
1.1.1) should not be delivered outside of the local domain.
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
[Page 8]
INTERNET DRAFT May 1997
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 an option for this nameserver session. Used without arguments
it return the settable options.
C: set verbose=off
S: 200:Done.
C: set
S: -200:echo:off
S: -200:limit:2
S: -200:characterset: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
[Page 9]
INTERNET DRAFT May 1997
3.6.1. login
login [your-alias]
The "login" command allows you to identify yourself to the
Nameserver. More specifically, it identifies you with a particular
entry in the Nameserver and allows you to change the 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 your own
entry.
In order to use the "login" command, you must know both your ph alias
and your ph password. The dialogue as it appears to the user:
C: login foo
S: Enter nameserver password:
C: bar
S: 200:foo:Hi how are you?
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.
3.6.3. answer
answer encrypted-response
In response to the login command, the Nameserver responds with a ran-
dom challenge string. The Nameserver client encrypts the challenge
with the password supplied by the user and returns it 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)7X$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).
[Page 10]
INTERNET DRAFT May 1997
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. Availability of this command in the server is a
compile-time setting. It's use is strongly discouraged.
C: login ppomes
S: 301:E=@Y&VW^_9YVI;D5.[EB0:B)9Z#_&X$:2)\L$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 con-
ditions are true, then the email command will be accepted by the
server:
1) The connection to the server originates on port 1023 or less on
the client.
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).
[Page 11]
INTERNET DRAFT May 1997
Alias is the user's alias.
C: xlogin 16 ppomes
S: 301:DoKrbLogin started; send Kerberos mutual authenticator.
C: answer Ja8QO1cJHYz2IdWyg7uhAnixVqgCZQBWr64ciXYku1ktdu....
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 authenti-
cator, X9.9 device response, etc. Binary quantities are first base-
64 encoded.
3.7. add
add field=value...
This command is used to add new entries to the database. You must be
logged in and have special privileges to use "add".
C: add name="doe john" id="123456789" alias="j-doe"
S: 200:Ok.
3.8. query/ph
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. A return clause consists of the
word "return" followed by a list of fields or the word "all". If the
word "all" is used the all viewable fields will be returned.
3.9. delete
delete [field=]value...
This command is used to delete entire new entries from the database.
You must be logged in and have special privileges to use "delete".
[Page 12]
INTERNET DRAFT May 1997
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.
3.10. make
make field="value"...
The "make" command allows you to change fields in your own Nameserver
entry. In order to use the "make" command, you must first login to
the Nameserver.
3.11. force
force field="value"
The "force" command overrides the encryption requirement for fields
such as password that have the Encrypt property.
3.12. change
change [field=]value make field="value"...
This command is used to change one or more fields to the values
specified. The "change" command consists of two clauses, the
"change" clause and the "make" clause. The "change" clause deter-
mines which entries will be affected by the command. It uses the
same arguments as the selection clause of a "query" command. The
"make" clause specifies which field(s) will be changed and the new
value(s) of the specified field(s).
You must be logged in to use "change".
Change differs from the "make" command in that it can modify multiple
Ph entries simultaneously.
The "change" command obeys the Nameserver "limit" option, which can
be used to prevent changing the field contents of more entries than
intended.
3.13. help
help [{native|client} [topic ...]]
Prints help on the Nameserver as such or on specific clients . If
[Page 13]
INTERNET DRAFT May 1997
client is specified, it should be a valid Nameserver client identif-
ier, 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
S: 101:
S: The Nameserver echo option is set. The text of this response
S: is the command you just gave, which has not (yet) been executed.
3.14. quit/exit/stop
quit
Terminates the session with the Nameserver and causes the client to
exit.
C: quit
S: 200:Bye!
4. Miscellaneous
4.1. 4.1 Authors Addresses
Roland Hedberg
Umdac
Umea University
901 87 Umea
Sweden
<Roland.Hedberg@umdac.umu.se>
Paul Pomes
Qualcomm Inc
6455 Lusk Blvd
San Diego, CA
USA
<ppomes@qualcomm.com>
[Page 14]
INTERNET DRAFT May 1997
Appendix A
Default fields connected to different object types:
type
name
address
write
password
type=phone: Information you would find in a phonebook
phone
fax
type=person: Information about a human being
alias
forename
surname
group
email
public_key
nickname
www
acl
type=staff: Information about an employee
empno
department
supervisor
secretary
office_location
office_address
office_phone
title
pager
hours
type=unit: Information about an organizational unit
email
www
public_key
[Page 15]
INTERNET DRAFT May 1997
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
[Page 16]
INTERNET DRAFT May 1997
590 Remote queries not allowed.
598 Command unknown.
599 Syntax error.
600 Ambiguous or multiple match
[Page 17]
INTERNET DRAFT May 1997
Appendix C
Description of the client command language using the augmented
Backus-Naur Form (RFC822).
response = code:[index:][field:]text
code = [-] LDIG 2DIGIT
index = 1*SPACE number
field = 1*SPACE attribute
text = 1*(CHAR / SPACE / HTAB )
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 / qouted-pair )
attribute = 1*( ALPHA / DIGIT / "_" / "-" )
number = 1*(DIGIT)
quoted-string = <"> 1*(qtext/quoted-pair) <">
quoted-pair = "
qtext = 1*( CHAR / CR / SPEC1 / DELIMIT1 / DELIMIT2 / LWS )
set = '[' 1*(ALPHA/DIGIT) ']'
LWS = 1*([CRLF] (SPACE / HTAB))
CRLF = CR LF
[Page 18]
INTERNET DRAFT May 1997
S_SPEC = '*'/'+'/'?'
SPEC1 = "=" / "*" / "?" / "+" / "[" / "]"
SPEC2 = "
DELIMIT1 = SPACE / HTAB / LF
DELIMIT2 = "," / ";" / ":"
PRINTABLE = %d32..%d126
CTL = %d0..%d31 / %d127..%d160
ASCII = DIGIT / ALPHA / OTHER
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 = "(" / ")" / "-" / "." / "/"
"@" / "$" / "_" / "!" / "~" /
"'" / "#" / "&" / "<" / ">" /
"^" / "`" / "{" / "|" / "}"
[Page 19]
Expire in six months