Finger User Information Protocol
Extracted elements (24)
The predominant Finger implementations were derived from BSD UNIX at UC Berkeley, so this RFC bases its behavioral specification around the BSD version while attempting not to invalidate existing diverse implementations or impose unnecessary restrictions.
The {Q2} forwarding default is recommended to be 'refuse' rather than 'allow' because the cases warranting forwarding are far outnumbered by cases where it poses a security risk, particularly for hosts acting as gateways at a security perimeter where enabling {Q2} creates an unauthorized path through the perimeter.
The user information file ('plan' file) feature allows users to leave a short message included in Finger responses. The RFC deliberately leaves the implementation method to the implementor (e.g., a specially named file in the user's home directory), keeping the mechanism flexible.
Following the IP protocol suite principle, RUIPs should 'be liberal in what you accept.' The distinction between what a user types at an OS prompt (e.g., 'finger user@host') and what the RUIP actually receives ('user<CRLF>') means implementations must handle query parsing accordingly.
A {U}{C} query for a specific user MUST return at least the user's full name. If the user is logged in, at least as much information as returned by {C} for that user MUST also be returned. Additional information such as home phone, login status, and a user information file SHOULD be configurable.
Allowable names in the {U} field MUST include usernames or login names as defined by the system. When a name is ambiguous, the system administrator SHOULD be allowed to choose whether all possible derivations are returned.
An RUIP MUST accept the entire Finger query specification as defined, including both {Q1} and {Q2} forms. The principle of 'be liberal in what you accept' applies.
An RUIP MUST either provide or actively refuse the {Q2} query forwarding service. If it provides this service, it must open a connection to the rightmost host in the chain, forward the remaining query, relay the response back, and close only when the downstream RUIP closes its connection.
For a {C} (null) query requesting a list of all online users, an RUIP MUST either answer or actively refuse. If it answers, it MUST provide at least each user's full name; additional information such as terminal location, office phone, and idle time SHOULD be configurable by the system administrator.
The /W query token in {Q1} or {Q2} SHOULD be interpreted at the last RUIP in the chain to signify a higher level of verbosity in the user information output, or at worst be ignored.
Finger operates over TCP on port 79 (decimal). A client opens a TCP connection to the remote host's Finger port, the RUIP processes a one-line query, returns an answer, and then closes the connection normally.
The Finger query specification defines two query types: {Q1} ::= [{U}] [/W] {C} for local queries and {Q2} ::= [{U}]{H} [/W] {C} for forwarded queries, where {U} is a username, {H} is @hostname (recursive, allowing chained forwarding), and {C} is CRLF.
Vending machines are explicitly mentioned as a valid Finger host type: they SHOULD respond to a {C} request with a list of available items and to a {U}{C} request with a detailed count of the specified product or slot.
All Finger implementations SHOULD allow administrators to control which atoms of information (office location, phone numbers, idle time, full name, etc.) are returned per query, down to the minimum required response of the user's full name. This 'atomic discharge' capability is essential for site-specific security policy.
Allowing an RUIP to execute a user program in response to a Finger query is potentially dangerous. The RUIP MUST NOT allow system security to be compromised by such a program. Operating system bugs could be exploited via this mechanism, and the feature may not be worth the risk.
Allowing an RUIP to return content from user-modifiable files (plan files) is equivalent to permitting arbitrary information distribution about the system, effectively bypassing administrator-configured information controls. This risk should be explicitly understood before enabling the feature.
Finger client programs SHOULD by default filter all unprintable data, passing only printable 7-bit ASCII (32–126), tabs (ASCII 9), and CRLFs, to protect users against terminal escape code injection and similar attacks. Two optional modes SHOULD be provided: one allowing characters below ASCII 32 and one allowing characters above ASCII 126.
Finger discloses potentially sensitive information about users, including last login time, mail status, and recent correspondents. Sites should make an explicit decision about whether to run Finger and what information to expose, as existing implementations can reveal enough to track ongoing conversations.
Implementations SHOULD allow system administrators to log Finger queries for audit trail purposes.
Malicious users can exploit {U} ambiguity to enumerate most usernames on a system through clever or persistent use of partial-name queries. Refusal of {U} ambiguity responses should be considered alongside refusal of {C} list requests.
Sound implementation of Finger is of utmost importance; an RUIP SHOULD protect itself against malformed inputs and be subjected to penetration testing. Finger is explicitly identified as a security perimeter protocol comparable to Telnet, FTP, and SMTP, and was exploited by the Morris worm.
The system administrator SHOULD be able to turn off RUIP acceptance of {C} (online user list) queries. If disabled, the RUIP MUST return a service refusal message such as 'Finger online user list denied'.
The Finger connection lifecycle: (1) client opens TCP connection to port 79; (2) RUIP becomes available; (3) client sends a one-line query ({Q1} or {Q2}); (4) RUIP processes query and returns answer; (5) RUIP closes connection normally. For {Q2}, the intermediate RUIP must keep {F1-2} open until {F2-3} closes.
All data transferred MUST be in 7-bit ASCII format with no parity, and lines MUST end in CRLF (ASCII 13 followed by ASCII 10). Characters between ASCII 128 and 255 are reserved for genuine international data, not 7-bit ASCII with the parity bit set.