Network Working Group D.
Request for Comments: 1196 Center for Discrete Mathematics
Obsoletes: RFCs 1194, 742 Theoretical Computer
December 1990


The Finger User Information

Status of this

This memo defines a protocol for the exchange of user information
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited



This memo describes the Finger User Information Protocol. This is
simple protocol which provides an interface to a remote
information program

Based on RFC 742, a description of the original Finger protocol,
memo attempts to clarify the expected communication between the
ends of a Finger connection. It also tries not to invalidate
many existing implementations or add unnecessary restrictions to
original protocol definition. This edition corrects and clarifies
a minor way, RFC 1194.

Table of

1. Introduction ........................................... 2
1.1. Intent ............................................... 2
1.2. History .............................................. 3
1.3. Requirements ......................................... 3
2. Use of the protocol .................................... 3
2.1. Flow of events ....................................... 3
2.2. Data format .......................................... 4
2.3. Query specifications ................................. 4
2.4. RUIP {Q2} behavior ................................... 4
2.5. Expected RUIP response ............................... 5
2.5.1. {C} query .......................................... 5
2.5.2. {U}{C} query ....................................... 6
2.5.3. {U} ambiguity ...................................... 6
2.5.4. /W query token ..................................... 6
2.5.5. Vending machines ................................... 7
3. Security ............................................... 7



Zimmerman [Page 1]

RFC 1196 Finger December 1990


3.1. Implementation security .............................. 7
3.2. RUIP security ........................................ 7
3.2.1. {Q2} refusal ....................................... 7
3.2.2. {C} refusal ........................................ 8
3.2.3. Atomic discharge ................................... 8
3.2.4. User information files ............................. 8
3.2.5. Execution of user programs ......................... 9
3.2.6. {U} ambiguity ...................................... 9
3.2.7. Audit trails ....................................... 9
3.3. Client security ...................................... 9
4. Examples ............................................... 10
4.1. Example with a null command line ({C}) ............... 10
4.2. Example with name specified ({U}{C}) ................. 10
4.3. Example with ambiguous name specified ({U}{C}) ....... 11
4.4. Example of query type {Q2} ({U}{H}{H}{C}) ............ 11
5. Acknowledgments ........................................ 12
6. Security Considerations ................................ 12
7. Author's Address ....................................... 12

1.

1.1.

This memo describes the Finger User Information Protocol. This is
simple protocol which provides an interface to a remote
information program (RUIP).

Based on RFC 742, a description of the original Finger protocol,
memo attempts to clarify the expected communication between the
ends of a Finger connection. It also tries not to invalidate
many current implementations or add unnecessary restrictions to
original protocol definition

The most prevalent implementations of Finger today seem to
primarily derived from the BSD UNIX work at the University
California, Berkeley. Thus, this memo is based around the
version's behavior

However, the BSD version provides few options to tailor the
RUIP for a particular site's security policy, or to protect the
from dangerous data. Furthermore, there are MANY potential
holes that implementors and administrators need to be aware of
particularly since the purpose of this protocol is to
information about a system's users, a sensitive issue at best
Therefore, this memo makes a number of important security
and recommendations





Zimmerman [Page 2]

RFC 1196 Finger December 1990


1.2.

The FINGER program at SAIL, written by Les Earnest, was
inspiration for the NAME program on ITS. Earl Killian at MIT
Brian Harvey at SAIL were jointly responsible for implementing
original protocol

Ken Harrenstien is the author of RFC 742, "Name/Finger", which
memo began life as

1.3.

In this document, the words that are used to define the
of each particular requirement are capitalized. These words are

* "MUST

This word or the adjective "REQUIRED" means that the item is
absolute requirement of the specification

* "SHOULD

This word or the adjective "RECOMMENDED" means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and the
carefully weighed before choosing a different course

* "MAY

This word or the adjective "OPTIONAL" means that this item
truly optional. One vendor may choose to include the item
a particular marketplace requires it or because it enhances
product, for example; another vendor may omit the same item

An implementation is not compliant if it fails to satisfy one or
of the MUST requirements. An implementation that satisfies all
MUST and all the SHOULD requirements is said to be "
compliant"; one that satisfies all the MUST requirements but not
the SHOULD requirements is said to be "conditionally compliant".

2. Use of the

2.1. Flow of

Finger is based on the Transmission Control Protocol, using TCP
79 decimal (117 octal). A TCP connection is opened to a remote
on the Finger port. An RUIP becomes available on the remote end
the connection to process the request. The RUIP is sent a one



Zimmerman [Page 3]

RFC 1196 Finger December 1990


query based upon the Finger query specification. The RUIP
the query, returns an answer, then closes the connection normally

2.2. Data

Any data transferred MUST be in ASCII format, with no parity,
with lines ending in CRLF (ASCII 13 followed by ASCII 10).
excludes other character formats such as EBCDIC, etc. This
means that any characters between ASCII 128 and ASCII 255
truly be international data, not 7-bit ASCII with the parity bit set

2.3. Query

An RUIP MUST accept the entire Finger query specification

The Finger query specification is defined

{Q1} ::= [{U}] [/W] {C

{Q2} ::= [{U}]{H} [/W] {C

{U} ::=

{H} ::= @hostname | @hostname{H

{C} ::=
{H}, being recursive, means that there is no arbitrary limit on
number of @hostname tokens in the query. In examples of the {Q2}
request specification, the number of @hostname tokens is limited
two, simply for brevity

Be aware that {Q1} and {Q2} do not refer to a user typing "
user@host" from an operating system prompt. It refers to the
that an RUIP actually receives. So, if a user types "
user@host", the RUIP on the remote host receives "user",
which corresponds to {Q1}.

As with anything in the IP protocol suite, "be liberal in what
accept".

2.4. RUIP {Q2}

A query of {Q2} is a request to forward a query to another RUIP.
RUIP MUST either provide or actively refuse this forwarding
(see section 3.2.1). If an RUIP provides this service, it
conform to the following behavior




Zimmerman [Page 4]

RFC 1196 Finger December 1990


Given that

Host

opens a Finger connection to an RUIP on

.

gives the

RUIP a query of type {Q2}
(e.g., FOO@HOST1@HOST2).

It should be derived that

Host

is the right-most host in (i.e., HOST2)

Query is the remainder of after removing
right-most "@hostname" token in the query (i.e., FOO@HOST1)

And so

The

RUIP then must itself open a Finger connection
to

, using .

The

RUIP must return any information received from
to

via .

The

RUIP must close in normal circumstances
when the

RUIP closes .

2.5. Expected RUIP

For the most part, the output of an RUIP doesn't follow a
specification, since it is designed to be read by people instead
programs. It should mainly strive to be informative

Output of ANY query is subject to the discussion in the
section

2.5.1. {C}

A query of {C} is a request for a list of all online users. An
MUST either answer or actively refuse (see section 3.2.2). If
answers, then it MUST provide at least the user's full name.
system administrator SHOULD be allowed to include other
information (per section 3.2.3), such as

- terminal
- office
- office phone
- job
- idle time (number of minutes since last typed input,



Zimmerman [Page 5]

RFC 1196 Finger December 1990


since last job activity).

2.5.2. {U}{C}

A query of {U}{C} is a request for in-depth status of a
user {U}. If you really want to refuse this service, you
don't want to be running Finger in the first place

An answer MUST include at least the full name of the user. If
user is logged in, at least the same amount of information
by {C} for that user MUST also be returned by {U}{C}.

Since this is a query for information on a specific user, the
administrator SHOULD be allowed to choose to return additional
information (per section 3.2.3), such as

- office
- office phone
- home phone
- status of login (not logged in, logout time, etc
- user information

A user information file is a feature wherein a user may leave a
message that will be included in the response to Finger requests
(This is sometimes called a "plan" file.) This is easily
by (for example) having the program look for a specially named
file in the user's home directory or some common area; the
method is left to the implementor. The system administrator
be allowed to specifically turn this feature on and off. See
3.2.4 for caveats

There MAY be a way for the user to run a program in response to
Finger query. If this feature exists, the system
SHOULD be allowed to specifically turn it on and off. See
3.2.5 for caveats

2.5.3. {U}

Allowable "names" in the command line MUST include "user names"
"login names" as defined by the system. If a name is ambiguous,
system administrator SHOULD be allowed to choose whether or not
possible derivations should be returned in some fashion (per
3.2.6).

2.5.4. /W query

The token /W in the {Q1} or {Q2} query types SHOULD at best
interpreted at the last RUIP to signify a higher level of



Zimmerman [Page 6]

RFC 1196 Finger December 1990


in the user information output, or at worst be ignored

2.5.5. Vending

Vending machines SHOULD respond to a {C} request with a list of
items currently available for purchase and possible consumption
Vending machines SHOULD respond to a {U}{C} request with a
count or list of the particular product or product slot.
machines should NEVER NEVER EVER eat requests. Or money

3.

3.1. Implementation

Sound implementation of Finger is of the utmost importance
Implementations should be tested against various forms of attack.
particular, an RUIP SHOULD protect itself against malformed inputs
Vendors providing Finger with the operating system or
software should subject their implementations to penetration testing

Finger is one of the avenues for direct penetration, as the
worm pointed out quite vividly. Like Telnet, FTP and SMTP, Finger
one of the protocols at the security perimeter of a host
Accordingly, the soundness of the implementation is paramount.
implementation should receive just as much security scrutiny
design, implementation, and testing as Telnet, FTP, or SMTP

3.2. RUIP

Warning!! Finger discloses information about users; moreover,
information may be considered sensitive. Security
should make explicit decisions about whether to run Finger and
information should be provided in responses. One
implementation provides the time the user last logged in, the time
last read mail, whether unread mail was waiting for him, and who
most recent unread mail was from! This makes it possible to
conversations in progress and see where someone's attention
focused. Sites that are information-security conscious should
run Finger without an explicit understanding of how much
it is giving away

3.2.1. {Q2}

For individual site security concerns, the system
SHOULD be given an option to individually turn on or off
processing of {Q2}. If RUIP processing of {Q2} is turned off,
RUIP MUST return a service refusal message of some sort. "
forwarding service denied" is adequate. The purpose of this is



Zimmerman [Page 7]

RFC 1196 Finger December 1990


allow individual hosts to choose to not forward Finger requests,
if they do choose to, to do so consistently

Overall, there are few cases which would warrant processing of {Q2}
at all, and they are far outweighed by the number of cases
refusing to process {Q2}. In particular, be aware that if a
is part of security perimeter (that is, it is a gateway from
outside world to some set of interior machines), then turning {Q2}
provides a path through that security perimeter. Therefore, it
RECOMMENDED that the default of the {Q2} processing option be
refuse processing. It certainly should not be enabled in
machines without careful consideration of the security implications

3.2.2. {C}

For individual site security concerns, the system
SHOULD be given an option to individually turn on or off
acceptance of {C}. If RUIP processing of {C} is turned off, the
MUST return a service refusal message of some sort. "Finger
user list denied" is adequate. The purpose of this is to
individual hosts to choose to not list the users currently online

3.2.3. Atomic

All implementations of Finger SHOULD allow individual
administrators to tailor what atoms of information are returned to
query. For example

- Administrator A should be allowed to specifically choose
return office location, office phone number, home
number, and logged in/logout time

- Administrator B should be allowed to specifically choose
return only office location, and office phone number

- Administrator C should be allowed to specifically choose
return the minimum amount of required information, which
the person's full name

3.2.4. User information

Allowing an RUIP to return information out of a user-modifiable
should be seen as equivalent to allowing any information about
system to be freely distributed. That is, it is potentially the
as turning on all specifiable options. This information
breach can be done in a number of ways, some cleverly,
straightforwardly. This should disturb the sleep of
administrators who wish to control the returned information



Zimmerman [Page 8]

RFC 1196 Finger December 1990


3.2.5. Execution of user

Allowing an RUIP to run a user program in response to a Finger
is potentially dangerous. BE CAREFUL!! -- the RUIP MUST NOT
system security to be compromised by that program. Implementing
feature may be more trouble than it is worth, since there are
bugs in operating systems, which could be exploited via this type
mechanism

3.2.6. {U}

Be aware that a malicious user's clever and/or persistent use of
feature can result in a list of most of the usernames on a system
Refusal of {U} ambiguity should be considered in the same vein
refusal of {C} requests (see section 3.2.2).

3.2.7. Audit

Implementations SHOULD allow system administrators to log
queries

3.3. Client

It is expected that there will normally be some client program
the user runs to query the initial RUIP. By default, this
SHOULD filter any unprintable data, leaving only printable 7-
characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs
This is to protect against people playing with terminal escape codes
changing other peoples' X window names, or committing other
or confusing deeds. Two separate user options SHOULD be
to modify this behavior, so that users may choose to
international or control characters

- one to allow all characters less than ASCII 32

- another to allow all characters greater than ASCII 126

For environments that live and breathe international data, the
administrator SHOULD be given a mechanism to enable the latter
by default for all users on a particular system. This can be
via a global environment variable or similar mechanism










Zimmerman [Page 9]

RFC 1196 Finger December 1990


4.

4.1. Example with a null command line ({C})

Site: elbereth.rutgers.
Command line:
Login Name TTY Idle When
rinehart Mark J. Rinehart p0 1:11 Mon 12:15 019 Hill x3166
greenfie Stephen J. Greenfiel p1 Mon 15:46 542 Hill x3074
rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
brisco Thomas P. Brisco pe 2:09 Mon 13:37 h055 x2351
laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413

4.2. Example with name specified ({U}{C})

Site: dimacs.rutgers.
Command line: pirmann
Login name: pirmann In real life: David
Office: 016 Hill, x2443 Home phone: 989-8482
Directory: /dimacs/u1/pirmann Shell: /bin/
Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers
No unread
Project
Plan
Work Schedule, Summer 1990
Rutgers LCSR Operations, 908-932-2443

Monday 5pm - 12
Tuesday 5pm - 12
Wednesday 9am - 5
Thursday 9am - 5
Saturday 9am - 5

larf larf hoo









Zimmerman [Page 10]

RFC 1196 Finger December 1990


4.3. Example with ambiguous name specified ({U}{C})

Site: elbereth.rutgers.
Command line: ron Login name: spinner In real life: Ron
Office: Ops Cubby, x2443 Home phone: 463-7358
Directory: /u1/spinner Shell: /bin/
Last login Mon May 7 16:38 on ttyq
Plan
ught
ca
m
' ...
I . .
!
! !
p !





Login name: surak In real life: Ron
Office: 000 OMB Dou, x9256
Directory: /u2/surak Shell: /bin/
Last login Fri Jul 27 09:55 on ttyq
No Plan

Login name: etter In real life: Ron
Directory: /u2/etter Shell: /bin/
Never logged in
No Plan

4.4. Example of query type {Q2} ({U}{H}{H}{C})

Site: dimacs.rutgers.
Command line: hedrick@math.rutgers.edu@pilot.njin.net
[pilot.njin.net
[math.rutgers.edu
Login name: hedrick In real life: Charles
Office: 484 Hill, x3088
Directory: /math/u2/hedrick Shell: /bin/
Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.
No unread
No Plan





Zimmerman [Page 11]

RFC 1196 Finger December 1990


5.

Thanks to everyone in the Internet Engineering Task Force for
comments. Special thanks to Steve Crocker for his
recommendations and prose

6. Security

Security issues are discussed in Section 3.

7. Author's

David Paul
Center for Discrete Mathematics
Theoretical Computer
Rutgers
P.O. Box 1179
Piscataway, NJ 08855-1179

Phone: (908)932-4592

EMail: dpz@dimacs.rutgers.





























Zimmerman [Page 12]

---

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.



RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX

---