From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1196.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc1196.txt (limited to 'doc/rfc/rfc1196.txt') diff --git a/doc/rfc/rfc1196.txt b/doc/rfc/rfc1196.txt new file mode 100644 index 0000000..96a6647 --- /dev/null +++ b/doc/rfc/rfc1196.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group D. Zimmerman +Request for Comments: 1196 Center for Discrete Mathematics and +Obsoletes: RFCs 1194, 742 Theoretical Computer Science + December 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. This edition corrects and clarifies in + a minor way, RFC 1194. + +Table of Contents + +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. Introduction + +1.1. 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. + + + + + +Zimmerman [Page 2] + +RFC 1196 Finger December 1990 + + +1.2. 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. + +1.3. 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". + +2. Use of the protocol + +2.1. 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 + + + +Zimmerman [Page 3] + +RFC 1196 Finger December 1990 + + + query based upon the Finger query specification. The RUIP processes + the query, returns an answer, then closes the connection normally. + +2.2. Data format + + Any data transferred MUST be in ASCII format, with no parity, and + with lines ending in CRLF (ASCII 13 followed by ASCII 10). 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 7-bit ASCII with the parity bit set. + +2.3. 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} ::= + + {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", the RUIP on the remote host receives "user", + which corresponds to {Q1}. + + As with anything in the IP protocol suite, "be liberal in what you + accept". + +2.4. 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: + + + + +Zimmerman [Page 4] + +RFC 1196 Finger December 1990 + + + Given that: + + Host

opens a Finger connection to an RUIP on host +

. + +

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 the + 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 only + when the

RUIP closes . + +2.5. Expected RUIP response + + For the most part, the output of an RUIP doesn't follow a strict + specification, since it is designed to be read by people instead of + programs. It should mainly strive to be informative. + + Output of ANY query is subject to the discussion in the security + section. + +2.5.1. {C} query + + A query of {C} is a request for a list of all online users. An RUIP + MUST either answer or actively refuse (see section 3.2.2). If it + answers, then it MUST provide at least the user's full name. The + system administrator SHOULD be allowed to include other useful + information (per section 3.2.3), such as: + + - terminal location + - office location + - office phone number + - job name + - idle time (number of minutes since last typed input, or + + + +Zimmerman [Page 5] + +RFC 1196 Finger December 1990 + + + since last job activity). + +2.5.2. {U}{C} query + + A query of {U}{C} is a request for in-depth status of a specified + user {U}. If you really want to refuse this service, you probably + don't want to be running Finger in the first place. + + An answer MUST include at least the full name of the user. If the + user is logged in, at least the same amount of information returned + by {C} for that user MUST also be returned by {U}{C}. + + Since this is a query for information on a specific user, the system + administrator SHOULD be allowed to choose to return additional useful + information (per section 3.2.3), such as: + + - office location + - office phone number + - home phone number + - status of login (not logged in, logout time, etc) + - user information file + + A user information file is a feature wherein a user may leave a short + message that will be included in the response to Finger requests. + (This is sometimes called a "plan" file.) This is easily implemented + by (for example) having the program look for a specially named text + file in the user's home directory or some common area; the exact + method is left to the implementor. The system administrator SHOULD + be allowed to specifically turn this feature on and off. See section + 3.2.4 for caveats. + + There MAY be a way for the 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. See section + 3.2.5 for caveats. + +2.5.3. {U} ambiguity + + Allowable "names" in the command line 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 or not all + possible derivations should be returned in some fashion (per section + 3.2.6). + +2.5.4. /W query token + + The token /W in the {Q1} or {Q2} query types SHOULD at best be + interpreted at the last RUIP to signify a higher level of verbosity + + + +Zimmerman [Page 6] + +RFC 1196 Finger December 1990 + + + in the user information output, or at worst be ignored. + +2.5.5. Vending machines + + Vending machines SHOULD respond to a {C} request with a list of all + items currently available for purchase and possible consumption. + Vending machines SHOULD respond to a {U}{C} request with a detailed + count or list of the particular product or product slot. Vending + machines should NEVER NEVER EVER eat requests. Or money. + +3. Security + +3.1. Implementation security + + Sound implementation of Finger is of the utmost importance. + Implementations should be tested against various forms of attack. In + particular, an RUIP SHOULD protect itself against malformed inputs. + Vendors providing Finger with the operating system or network + software should subject their implementations to penetration testing. + + Finger is one of the avenues for direct penetration, as the Morris + worm pointed out quite vividly. Like Telnet, FTP and SMTP, Finger is + one of the protocols at the security perimeter of a host. + Accordingly, the soundness of the implementation is paramount. The + implementation should receive just as much security scrutiny during + design, implementation, and testing as Telnet, FTP, or SMTP. + +3.2. RUIP security + + Warning!! Finger discloses information about users; moreover, such + information may be considered sensitive. Security administrators + should make explicit decisions about whether to run Finger and what + information should be provided in responses. One existing + implementation provides the time the user last logged in, the time he + last read mail, whether unread mail was waiting for him, and who the + most recent unread mail was from! This makes it possible to track + conversations in progress and see where someone's attention was + focused. Sites that are information-security conscious should not + run Finger without an explicit understanding of how much information + it is giving away. + +3.2.1. {Q2} refusal + + For individual site security concerns, the system administrator + SHOULD be given an option to individually turn on or off RUIP + processing of {Q2}. If RUIP processing of {Q2} is turned off, the + RUIP MUST return a service refusal message of some sort. "Finger + forwarding service denied" is adequate. The purpose of this is to + + + +Zimmerman [Page 7] + +RFC 1196 Finger December 1990 + + + allow individual hosts to choose to not forward Finger requests, but + 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 for + refusing to process {Q2}. In particular, be aware that if a machine + is part of security perimeter (that is, it is a gateway from the + outside world to some set of interior machines), then turning {Q2} on + provides a path through that security perimeter. Therefore, it is + RECOMMENDED that the default of the {Q2} processing option be to + refuse processing. It certainly should not be enabled in gateway + machines without careful consideration of the security implications. + +3.2.2. {C} refusal + + For individual site security concerns, the system administrator + SHOULD be given an option to individually turn on or off RUIP + acceptance of {C}. If RUIP processing of {C} is turned off, the RUIP + MUST return a service refusal message of some sort. "Finger online + user list denied" is adequate. The purpose of this is to allow + individual hosts to choose to not list the users currently online. + +3.2.3. Atomic discharge + + All implementations of Finger SHOULD allow individual system + administrators to tailor what atoms of information are returned to a + query. For example: + + - Administrator A should be allowed to specifically choose to + return office location, office phone number, home phone + number, and logged in/logout time. + + - Administrator B should be allowed to specifically choose to + return only office location, and office phone number. + + - Administrator C should be allowed to specifically choose to + return the minimum amount of required information, which is + the person's full name. + +3.2.4. User information files + + Allowing an RUIP to return information out of a user-modifiable file + should be seen as equivalent to allowing any information about your + system to be freely distributed. That is, it is potentially the same + as turning on all specifiable options. This information security + breach can be done in a number of ways, some cleverly, others + straightforwardly. This should disturb the sleep of system + administrators who wish to control the returned information. + + + +Zimmerman [Page 8] + +RFC 1196 Finger December 1990 + + +3.2.5. Execution of user programs + + Allowing an RUIP to run a user program in response to a Finger query + is potentially dangerous. BE CAREFUL!! -- the RUIP MUST NOT allow + system security to be compromised by that program. Implementing this + feature may be more trouble than it is worth, since there are always + bugs in operating systems, which could be exploited via this type of + mechanism. + +3.2.6. {U} ambiguity + + Be aware that a malicious user's clever and/or persistent use of this + 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 as + refusal of {C} requests (see section 3.2.2). + +3.2.7. Audit trails + + Implementations SHOULD allow system administrators to log Finger + queries. + +3.3. Client security + + It is expected that there will normally be some client program that + the user runs to query the initial RUIP. By default, this program + SHOULD filter any unprintable data, leaving only printable 7-bit + 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 dastardly + or confusing deeds. Two separate user options SHOULD be considered + to modify this behavior, so that users may choose to view + 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 system + administrator SHOULD be given a mechanism to enable the latter option + by default for all users on a particular system. This can be done + via a global environment variable or similar mechanism. + + + + + + + + + + +Zimmerman [Page 9] + +RFC 1196 Finger December 1990 + + +4. Examples + +4.1. Example with a null command line ({C}) + +Site: elbereth.rutgers.edu +Command line: + +Login Name TTY Idle When Office +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.edu +Command line: pirmann + +Login name: pirmann In real life: David Pirmann +Office: 016 Hill, x2443 Home phone: 989-8482 +Directory: /dimacs/u1/pirmann Shell: /bin/tcsh +Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers. +No unread mail +Project: +Plan: + Work Schedule, Summer 1990 + Rutgers LCSR Operations, 908-932-2443 + + Monday 5pm - 12am + Tuesday 5pm - 12am + Wednesday 9am - 5pm + Thursday 9am - 5pm + Saturday 9am - 5pm + + larf larf hoo hoo + + + + + + + + + +Zimmerman [Page 10] + +RFC 1196 Finger December 1990 + + +4.3. Example with ambiguous name specified ({U}{C}) + +Site: elbereth.rutgers.edu +Command line: ron +Login name: spinner In real life: Ron Spinner +Office: Ops Cubby, x2443 Home phone: 463-7358 +Directory: /u1/spinner Shell: /bin/tcsh +Last login Mon May 7 16:38 on ttyq7 +Plan: + ught i + ca n + m a + ' ... t + I . . i + ! m + ! ! e + p !pool + l + e + H + + +Login name: surak In real life: Ron Surak +Office: 000 OMB Dou, x9256 +Directory: /u2/surak Shell: /bin/tcsh +Last login Fri Jul 27 09:55 on ttyq3 +No Plan. + +Login name: etter In real life: Ron Etter +Directory: /u2/etter Shell: /bin/tcsh +Never logged in. +No Plan. + +4.4. Example of query type {Q2} ({U}{H}{H}{C}) + +Site: dimacs.rutgers.edu +Command line: hedrick@math.rutgers.edu@pilot.njin.net + +[pilot.njin.net] +[math.rutgers.edu] +Login name: hedrick In real life: Charles Hedrick +Office: 484 Hill, x3088 +Directory: /math/u2/hedrick Shell: /bin/tcsh +Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge +No unread mail +No Plan. + + + + + +Zimmerman [Page 11] + +RFC 1196 Finger December 1990 + + +5. Acknowledgments + + Thanks to everyone in the Internet Engineering Task Force for their + comments. Special thanks to Steve Crocker for his security + recommendations and prose. + +6. Security Considerations + + Security issues are discussed in Section 3. + +7. Author's Address + + David Paul Zimmerman + Center for Discrete Mathematics and + Theoretical Computer Science + Rutgers University + P.O. Box 1179 + Piscataway, NJ 08855-1179 + + Phone: (908)932-4592 + + EMail: dpz@dimacs.rutgers.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zimmerman [Page 12] + \ No newline at end of file -- cgit v1.2.3