Finger User Information Protocol
Extracted elements (24)
The {Q2} forwarding default is RECOMMENDED to be 'refuse' because cases warranting forwarding are far outnumbered by cases against it. Enabling {Q2} on a security gateway creates an unintended path through the security perimeter.
This memo is based primarily on the BSD UNIX Finger implementation from UC Berkeley, as it represents the most prevalent implementation. The BSD version provides few options for tailoring security policy, which motivates the explicit security recommendations added in this memo.
Vending machines SHOULD respond to a {C} request with a list of all items currently available for purchase, and to a {U}{C} request with a detailed count or list of a particular product or product slot, illustrating the protocol's extension beyond traditional user information.
Allowable names in the {U} field MUST include 'user names' or 'login names' as defined by the system. If 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, covering both {Q1} and {Q2} query types. Consistent with IP suite philosophy, implementations should be liberal in what they accept.
An RUIP MUST either provide or actively refuse the {Q2} forwarding service. If it provides forwarding, it must open a connection to the right-most @hostname in the query, pass along the remaining query, relay the full response, and close the connection only when the remote RUIP closes its side.
Any data transferred MUST be in ASCII format, with no parity, and with lines ending in CRLF. Other character formats such as EBCDIC are excluded; characters between ASCII 128 and 255 should represent genuine international data, not USASCII with parity set.
By default, client programs SHOULD filter any unprintable data from RUIP responses, retaining only USASCII characters and CRLF, to protect against VT100 escape code attacks and similar abuses. Two user options SHOULD be available to allow characters below ASCII 32 or above ASCII 126.
For a {C} (null) query requesting all online users, an RUIP MUST either answer or actively refuse. If it answers, it MUST provide at least the full name of each online user.
For a {U}{C} query, the response MUST include at least the full name of the specified user. If the user is logged in, at minimum the same information returned by a {C} query for that user MUST also be returned.
If an RUIP supports execution of user programs in response to Finger queries, the RUIP MUST NOT allow system security to be compromised by that program, given the persistent risk of exploitable operating system bugs.
Implementations SHOULD allow system administrators to log Finger queries to maintain audit trails.
There MAY be a way for a user to run a program in response to a Finger query. If this feature exists, the system administrator SHOULD be allowed to specifically turn it on and off.
A user information file (commonly called a 'plan' file) is a user-modifiable text file, typically in the user's home directory, whose contents are included in the {U}{C} response. The system administrator SHOULD be able to specifically turn this feature on and off.
Finger operates over TCP on port 79 (decimal, 117 octal). A client opens a TCP connection to the remote host's Finger port, the RUIP processes the one-line query, returns an answer, and then closes the connection normally.
For {Q2} forwarding, the RUIP derives the target host {H3} as the right-most @hostname token and the forwarded query {Q2-3} as the remainder after removing that token. It then opens a new Finger connection to {H3} with {Q2-3} and relays the response back to the originating client.
The /W token in {Q1} or {Q2} query types SHOULD be interpreted at the last RUIP to signify a higher level of verbosity in the user information output, or at worst be ignored.
A malicious user's persistent use of {U} ambiguity can enumerate most usernames on a system. Administrators should consider refusing ambiguous {U} queries in the same vein as refusing {C} requests.
All Finger implementations SHOULD allow system administrators to choose which atoms of information are returned (e.g., office location, phone number, login/logout time), enabling fine-grained control over the information disclosed. The minimum required is the person's full name.
Allowing an RUIP to return information from user-modifiable plan files is equivalent to allowing any information about the system to be freely distributed; it may bypass the administrator's disclosure controls in subtle and clever ways.
Finger discloses information about users that may be considered sensitive, including login times, mail status, and communication patterns. Security administrators should make explicit decisions about whether to run Finger and what information to provide in responses.
Sound implementation of Finger is paramount; RUIPs SHOULD protect against malformed inputs and implementations should be subjected to penetration testing. Finger is at the security perimeter of a host, comparable to Telnet, FTP, and SMTP, as demonstrated by the Morris worm.
The system administrator SHOULD have the option to disable {C} user-list queries. If disabled, the RUIP MUST return a service refusal message such as 'Finger online user list denied'.
The Finger query grammar defines two query types: {Q1} ::= [{U}] [/W] {C} for local queries, and {Q2} ::= [{U}]{H} [/W] {C} for forwarded queries, where {H} ::= @hostname | @hostname{H} (recursive), {U} is a username, and {C} is CRLF.