RFC1194
Network Working Group D. Zimmerman Request for Comments: 1194 Center for Discrete Mathematics and Obsoletes: RFC 742 Theoretical Computer Science
November 1990
The Finger User Information Protocol
Status of this Memo
This memo defines a protocol for the exchange of user information. This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Abstract
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program.
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many existing implementations or add unnecessary restrictions to the original protocol definition.
Contents
- 1 Introduction
- 2 Use of the protocol
- 3 opens a Finger connection <F1-2> to an RUIP on host . gives the RUIP a query <Q1-2> of type {Q2} (e.g., FOO@HOST1@HOST2). It should be derived that: Host is the right-most host in <Q1-2> (i.e., HOST2) Query <Q2-3> is the remainder of <Q1-2> after removing the right-most "@hostname" token in the query (i.e., FOO@HOST1) And so: The RUIP then must itself open a Finger connection <F2-3> to , using <Q2-3>. The RUIP must return any information received from <F2-3> to via <F1-2>. The RUIP must close <F1-2> in normal circumstances only when the RUIP closes <F2-3>. Expected RUIP response
Introduction
Intent
This memo describes the Finger User Information Protocol. This is a simple protocol which provides an interface to a remote user information program (RUIP).
Based on RFC 742, a description of the original Finger protocol, this memo attempts to clarify the expected communication between the two ends of a Finger connection. It also tries not to invalidate the many current implementations or add unnecessary restrictions to the original protocol definition.
The most prevalent implementations of Finger today seem to be primarily derived from the BSD UNIX work at the University of California, Berkeley. Thus, this memo is based around the BSD version's behavior.
However, the BSD version provides few options to tailor the Finger RUIP for a particular site's security policy, or to protect the user from dangerous data. Furthermore, there are MANY potential security holes that implementors and administrators need to be aware of, particularly since the purpose of this protocol is to return information about a system's users, a sensitive issue at best. Therefore, this memo makes a number of important security comments and recommendations.
History
The FINGER program at SAIL, written by Les Earnest, was the inspiration for the NAME program on ITS. Earl Killian at MIT and Brian Harvey at SAIL were jointly responsible for implementing the original protocol.
Ken Harrenstien is the author of RFC 742, "Name/Finger", which this memo began life as.
Requirements
In this document, the words that are used to define the significance of each particular requirement are capitalized. These words are:
- "MUST"
This word or the adjective "REQUIRED" means that the item is an absolute requirement of the specification.
- "SHOULD"
This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
- "MAY"
This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements. An implementation that satisfies all the MUST and all the SHOULD requirements is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements is said to be "conditionally compliant".
Use of the protocol
Flow of events
Finger is based on the Transmission Control Protocol, using TCP port 79 decimal (117 octal). A TCP connection is opened to a remote host on the Finger port. An RUIP becomes available on the remote end of the connection to process the request. The RUIP is sent a one line
query based upon the Finger query specification. The RUIP processes the query, returns an answer, then closes the connection normally.
Data format
Any data transferred MUST be in ASCII format, with no parity, and with lines ending in CRLF. This excludes other character formats such as EBCDIC, etc. This also means that any characters between ASCII 128 and ASCII 255 should truly be international data, not USASCII with the parity bit set.
Query specifications
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} ::= username
{H} ::= @hostname | @hostname{H}
{C} ::= <CRLF>
{H}, being recursive, means that there is no arbitrary limit on the number of @hostname tokens in the query. In examples of the {Q2} request specification, the number of @hostname tokens is limited to two, simply for brevity.
Be aware that {Q1} and {Q2} do not refer to a user typing "finger user@host" from an operating system prompt. It refers to the line that an RUIP actually receives. So, if a user types "finger user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>", which corresponds to {Q1}.
As with anything in the IP protocol suite, "be liberal in what you accept".
RUIP {Q2} behavior
A query of {Q2} is a request to forward a query to another RUIP. An RUIP MUST either provide or actively refuse this forwarding service (see section 3.2.1). If an RUIP provides this service, it MUST conform to the following behavior:
Given that:
Host