info - fingered - Fingerd protocol daemon, allowing custom responses.
(HTM) git clone git://jay.scot/fingered
(DIR) Log
(DIR) Files
(DIR) Refs
(DIR) README
(DIR) LICENSE
---
info (25132B)
---
1 Network Working Group D. Zimmerman
2 Request for Comments: 1288 Center for Discrete Mathematics and
3 Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science
4 December 1991
5
6
7 The Finger User Information Protocol
8
9 Status of this Memo
10
11 This memo defines a protocol for the exchange of user information.
12 This RFC specifies an IAB standards track protocol for the Internet
13 community, and requests discussion and suggestions for improvements.
14 Please refer to the current edition of the "IAB Official Protocol
15 Standards" for the standardization state and status of this protocol.
16 Distribution of this memo is unlimited.
17
18 Abstract
19
20 This memo describes the Finger user information protocol. This is a
21 simple protocol which provides an interface to a remote user
22 information program.
23
24 Based on RFC 742, a description of the original Finger protocol, this
25 memo attempts to clarify the expected communication between the two
26 ends of a Finger connection. It also tries not to invalidate the
27 many existing implementations or add unnecessary restrictions to the
28 original protocol definition.
29
30 This edition corrects and clarifies RFC 1196.
31
32 Table of Contents
33
34 1. Introduction ........................................... 2
35 1.1. Intent ............................................... 2
36 1.2. History .............................................. 3
37 1.3. Requirements ......................................... 3
38 1.4. Updates .............................................. 3
39 2. Use of the protocol .................................... 4
40 2.1. Flow of events ....................................... 4
41 2.2. Data format .......................................... 4
42 2.3. Query specifications ................................. 4
43 2.4. RUIP {Q2} behavior ................................... 5
44 2.5. Expected RUIP response ............................... 6
45 2.5.1. {C} query .......................................... 6
46 2.5.2. {U}{C} query ....................................... 6
47 2.5.3. {U} ambiguity ...................................... 7
48 2.5.4. /W query token ..................................... 7
49
50
51
52 Zimmerman [Page 1]
53
54 RFC 1288 Finger December 1991
55
56
57 2.5.5. Vending machines ................................... 7
58 3. Security ............................................... 7
59 3.1. Implementation security .............................. 7
60 3.2. RUIP security ........................................ 8
61 3.2.1. {Q2} refusal ....................................... 8
62 3.2.2. {C} refusal ........................................ 8
63 3.2.3. Atomic discharge ................................... 8
64 3.2.4. User information files ............................. 9
65 3.2.5. Execution of user programs ......................... 9
66 3.2.6. {U} ambiguity ...................................... 9
67 3.2.7. Audit trails ....................................... 9
68 3.3. Client security ...................................... 9
69 4. Examples ............................................... 10
70 4.1. Example with a null command line ({C}) ............... 10
71 4.2. Example with name specified ({U}{C}) ................. 10
72 4.3. Example with ambiguous name specified ({U}{C}) ....... 11
73 4.4. Example of query type {Q2} ({U}{H}{H}{C}) ............ 11
74 5. Acknowledgments ........................................ 12
75 6. Security Considerations ................................ 12
76 7. Author's Address ....................................... 12
77
78 1. Introduction
79
80 1.1. Intent
81
82 This memo describes the Finger user information protocol. This is a
83 simple protocol which provides an interface to a remote user
84 information program (RUIP).
85
86 Based on RFC 742, a description of the original Finger protocol, this
87 memo attempts to clarify the expected communication between the two
88 ends of a Finger connection. It also tries not to invalidate the
89 many current implementations or add unnecessary restrictions to the
90 original protocol definition.
91
92 The most prevalent implementations of Finger today seem to be
93 primarily derived from the BSD UNIX work at the University of
94 California, Berkeley. Thus, this memo is based around the BSD
95 version's behavior.
96
97 However, the BSD version provides few options to tailor the Finger
98 RUIP for a particular site's security policy, or to protect the user
99 from dangerous data. Furthermore, there are MANY potential security
100 holes that implementors and administrators need to be aware of,
101 particularly since the purpose of this protocol is to return
102 information about a system's users, a sensitive issue at best.
103 Therefore, this memo makes a number of important security comments
104 and recommendations.
105
106
107
108 Zimmerman [Page 2]
109
110 RFC 1288 Finger December 1991
111
112
113 1.2. History
114
115 The FINGER program at SAIL, written by Les Earnest, was the
116 inspiration for the NAME program on ITS. Earl Killian at MIT and
117 Brian Harvey at SAIL were jointly responsible for implementing the
118 original protocol.
119
120 Ken Harrenstien is the author of RFC 742, "Name/Finger", which this
121 memo began life as.
122
123 1.3. Requirements
124
125 In this document, the words that are used to define the significance
126 of each particular requirement are capitalized. These words are:
127
128 * "MUST"
129
130 This word or the adjective "REQUIRED" means that the item is an
131 absolute requirement of the specification.
132
133 * "SHOULD"
134
135 This word or the adjective "RECOMMENDED" means that there may
136 exist valid reasons in particular circumstances to ignore this
137 item, but the full implications should be understood and the case
138 carefully weighed before choosing a different course.
139
140 * "MAY"
141
142 This word or the adjective "OPTIONAL" means that this item is
143 truly optional. One vendor may choose to include the item because
144 a particular marketplace requires it or because it enhances the
145 product, for example; another vendor may omit the same item.
146
147 An implementation is not compliant if it fails to satisfy one or more
148 of the MUST requirements. An implementation that satisfies all the
149 MUST and all the SHOULD requirements is said to be "unconditionally
150 compliant"; one that satisfies all the MUST requirements but not all
151 the SHOULD requirements is said to be "conditionally compliant".
152
153 1.4. Updates
154
155 The differences of note between RFC 1196 and this memo are:
156
157 o the optional /W switch in the Finger query specification was
158 mistakenly placed at the end of the line. The 4.3BSD Finger
159 specifies it at the beginning, where this memo now also puts
160 it.
161
162
163
164 Zimmerman [Page 3]
165
166 RFC 1288 Finger December 1991
167
168
169 o the BNF in the Finger query specification was not clear on the
170 treatment of blank space. This memo is more exacting by
171 including an explicit token for it.
172
173 o The flow of events in a Finger connection is now better
174 defined on the topic of the close of the Finger connection.
175
176 2. Use of the protocol
177
178 2.1. Flow of events
179
180 Finger is based on the Transmission Control Protocol, using TCP port
181 79 decimal (117 octal). The local host opens a TCP connection to a
182 remote host on the Finger port. An RUIP becomes available on the
183 remote end of the connection to process the request. The local host
184 sends the RUIP a one line query based upon the Finger query
185 specification, and waits for the RUIP to respond. The RUIP receives
186 and processes the query, returns an answer, then initiates the close
187 of the connection. The local host receives the answer and the close
188 signal, then proceeds closing its end of the connection.
189
190 2.2. Data format
191
192 Any data transferred MUST be in ASCII format, with no parity, and
193 with lines ending in CRLF (ASCII 13 followed by ASCII 10). This
194 excludes other character formats such as EBCDIC, etc. This also
195 means that any characters between ASCII 128 and ASCII 255 should
196 truly be international data, not 7-bit ASCII with the parity bit set.
197
198 2.3. Query specifications
199
200 An RUIP MUST accept the entire Finger query specification.
201
202 The Finger query specification is defined:
203
204 {Q1} ::= [{W}|{W}{S}{U}]{C}
205
206 {Q2} ::= [{W}{S}][{U}]{H}{C}
207
208 {U} ::= username
209
210 {H} ::= @hostname | @hostname{H}
211
212 {W} ::= /W
213
214 {S} ::= <SP> | <SP>{S}
215
216 {C} ::= <CRLF>
217
218
219
220 Zimmerman [Page 4]
221
222 RFC 1288 Finger December 1991
223
224
225 {H}, being recursive, means that there is no arbitrary limit on the
226 number of @hostname tokens in the query. In examples of the {Q2}
227 request specification, the number of @hostname tokens is limited to
228 two, simply for brevity.
229
230 Be aware that {Q1} and {Q2} do not refer to a user typing "finger
231 user@host" from an operating system prompt. It refers to the line
232 that an RUIP actually receives. So, if a user types "finger
233 user@host<CRLF>", the RUIP on the remote host receives "user<CRLF>",
234 which corresponds to {Q1}.
235
236 As with anything in the IP protocol suite, "be liberal in what you
237 accept".
238
239 2.4. RUIP {Q2} behavior
240
241 A query of {Q2} is a request to forward a query to another RUIP. An
242 RUIP MUST either provide or actively refuse this forwarding service
243 (see section 3.2.1). If an RUIP provides this service, it MUST
244 conform to the following behavior:
245
246 Given that:
247
248 Host <H1> opens a Finger connection <F1-2> to an RUIP on host
249 <H2>.
250
251 <H1> gives the <H2> RUIP a query <Q1-2> of type {Q2}
252 (e.g., FOO@HOST1@HOST2).
253
254 It should be derived that:
255
256 Host <H3> is the right-most host in <Q1-2> (i.e., HOST2)
257
258 Query <Q2-3> is the remainder of <Q1-2> after removing the
259 right-most "@hostname" token in the query (i.e., FOO@HOST1)
260
261 And so:
262
263 The <H2> RUIP then must itself open a Finger connection <F2-3>
264 to <H3>, using <Q2-3>.
265
266 The <H2> RUIP must return any information received from <F2-3>
267 to <H1> via <F1-2>.
268
269 The <H2> RUIP must close <F1-2> in normal circumstances only
270 when the <H3> RUIP closes <F2-3>.
271
272
273
274
275
276 Zimmerman [Page 5]
277
278 RFC 1288 Finger December 1991
279
280
281 2.5. Expected RUIP response
282
283 For the most part, the output of an RUIP doesn't follow a strict
284 specification, since it is designed to be read by people instead of
285 programs. It should mainly strive to be informative.
286
287 Output of ANY query is subject to the discussion in the security
288 section.
289
290 2.5.1. {C} query
291
292 A query of {C} is a request for a list of all online users. An RUIP
293 MUST either answer or actively refuse (see section 3.2.2). If it
294 answers, then it MUST provide at least the user's full name. The
295 system administrator SHOULD be allowed to include other useful
296 information (per section 3.2.3), such as:
297
298 - terminal location
299 - office location
300 - office phone number
301 - job name
302 - idle time (number of minutes since last typed input, or
303 since last job activity).
304
305 2.5.2. {U}{C} query
306
307 A query of {U}{C} is a request for in-depth status of a specified
308 user {U}. If you really want to refuse this service, you probably
309 don't want to be running Finger in the first place.
310
311 An answer MUST include at least the full name of the user. If the
312 user is logged in, at least the same amount of information returned
313 by {C} for that user MUST also be returned by {U}{C}.
314
315 Since this is a query for information on a specific user, the system
316 administrator SHOULD be allowed to choose to return additional useful
317 information (per section 3.2.3), such as:
318
319 - office location
320 - office phone number
321 - home phone number
322 - status of login (not logged in, logout time, etc)
323 - user information file
324
325 A user information file is a feature wherein a user may leave a short
326 message that will be included in the response to Finger requests.
327 (This is sometimes called a "plan" file.) This is easily implemented
328 by (for example) having the program look for a specially named text
329
330
331
332 Zimmerman [Page 6]
333
334 RFC 1288 Finger December 1991
335
336
337 file in the user's home directory or some common area; the exact
338 method is left to the implementor. The system administrator SHOULD
339 be allowed to specifically turn this feature on and off. See section
340 3.2.4 for caveats.
341
342 There MAY be a way for the user to run a program in response to a
343 Finger query. If this feature exists, the system administrator
344 SHOULD be allowed to specifically turn it on and off. See section
345 3.2.5 for caveats.
346
347 2.5.3. {U} ambiguity
348
349 Allowable "names" in the command line MUST include "user names" or
350 "login names" as defined by the system. If a name is ambiguous, the
351 system administrator SHOULD be allowed to choose whether or not all
352 possible derivations should be returned in some fashion (per section
353 3.2.6).
354
355 2.5.4. /W query token
356
357 The token /W in the {Q1} or {Q2} query types SHOULD at best be
358 interpreted at the last RUIP to signify a higher level of verbosity
359 in the user information output, or at worst be ignored.
360
361 2.5.5. Vending machines
362
363 Vending machines SHOULD respond to a {C} request with a list of all
364 items currently available for purchase and possible consumption.
365 Vending machines SHOULD respond to a {U}{C} request with a detailed
366 count or list of the particular product or product slot. Vending
367 machines should NEVER NEVER EVER eat money.
368
369 3. Security
370
371 3.1. Implementation security
372
373 Sound implementation of Finger is of the utmost importance.
374 Implementations should be tested against various forms of attack. In
375 particular, an RUIP SHOULD protect itself against malformed inputs.
376 Vendors providing Finger with the operating system or network
377 software should subject their implementations to penetration testing.
378
379 Finger is one of the avenues for direct penetration, as the Morris
380 worm pointed out quite vividly. Like Telnet, FTP and SMTP, Finger is
381 one of the protocols at the security perimeter of a host.
382 Accordingly, the soundness of the implementation is paramount. The
383 implementation should receive just as much security scrutiny during
384 design, implementation, and testing as Telnet, FTP, or SMTP.
385
386
387
388 Zimmerman [Page 7]
389
390 RFC 1288 Finger December 1991
391
392
393 3.2. RUIP security
394
395 Warning!! Finger discloses information about users; moreover, such
396 information may be considered sensitive. Security administrators
397 should make explicit decisions about whether to run Finger and what
398 information should be provided in responses. One existing
399 implementation provides the time the user last logged in, the time he
400 last read mail, whether unread mail was waiting for him, and who the
401 most recent unread mail was from! This makes it possible to track
402 conversations in progress and see where someone's attention was
403 focused. Sites that are information-security conscious should not
404 run Finger without an explicit understanding of how much information
405 it is giving away.
406
407 3.2.1. {Q2} refusal
408
409 For individual site security concerns, the system administrator
410 SHOULD be given an option to individually turn on or off RUIP
411 processing of {Q2}. If RUIP processing of {Q2} is turned off, the
412 RUIP MUST return a service refusal message of some sort. "Finger
413 forwarding service denied" is adequate. The purpose of this is to
414 allow individual hosts to choose to not forward Finger requests, but
415 if they do choose to, to do so consistently.
416
417 Overall, there are few cases which would warrant processing of {Q2}
418 at all, and they are far outweighed by the number of cases for
419 refusing to process {Q2}. In particular, be aware that if a machine
420 is part of security perimeter (that is, it is a gateway from the
421 outside world to some set of interior machines), then turning {Q2} on
422 provides a path through that security perimeter. Therefore, it is
423 RECOMMENDED that the default of the {Q2} processing option be to
424 refuse processing. It certainly should not be enabled in gateway
425 machines without careful consideration of the security implications.
426
427 3.2.2. {C} refusal
428
429 For individual site security concerns, the system administrator
430 SHOULD be given an option to individually turn on or off RUIP
431 acceptance of {C}. If RUIP processing of {C} is turned off, the RUIP
432 MUST return a service refusal message of some sort. "Finger online
433 user list denied" is adequate. The purpose of this is to allow
434 individual hosts to choose to not list the users currently online.
435
436 3.2.3. Atomic discharge
437
438 All implementations of Finger SHOULD allow individual system
439 administrators to tailor what atoms of information are returned to a
440 query. For example:
441
442
443
444 Zimmerman [Page 8]
445
446 RFC 1288 Finger December 1991
447
448
449 - Administrator A should be allowed to specifically choose to
450 return office location, office phone number, home phone
451 number, and logged in/logout time.
452
453 - Administrator B should be allowed to specifically choose to
454 return only office location, and office phone number.
455
456 - Administrator C should be allowed to specifically choose to
457 return the minimum amount of required information, which is
458 the person's full name.
459
460 3.2.4. User information files
461
462 Allowing an RUIP to return information out of a user-modifiable file
463 should be seen as equivalent to allowing any information about your
464 system to be freely distributed. That is, it is potentially the same
465 as turning on all specifiable options. This information security
466 breach can be done in a number of ways, some cleverly, others
467 straightforwardly. This should disturb the sleep of system
468 administrators who wish to control the returned information.
469
470 3.2.5. Execution of user programs
471
472 Allowing an RUIP to run a user program in response to a Finger query
473 is potentially dangerous. BE CAREFUL!! -- the RUIP MUST NOT allow
474 system security to be compromised by that program. Implementing this
475 feature may be more trouble than it is worth, since there are always
476 bugs in operating systems, which could be exploited via this type of
477 mechanism.
478
479 3.2.6. {U} ambiguity
480
481 Be aware that a malicious user's clever and/or persistent use of this
482 feature can result in a list of most of the usernames on a system.
483 Refusal of {U} ambiguity should be considered in the same vein as
484 refusal of {C} requests (see section 3.2.2).
485
486 3.2.7. Audit trails
487
488 Implementations SHOULD allow system administrators to log Finger
489 queries.
490
491 3.3. Client security
492
493 It is expected that there will normally be some client program that
494 the user runs to query the initial RUIP. By default, this program
495 SHOULD filter any unprintable data, leaving only printable 7-bit
496 characters (ASCII 32 through ASCII 126), tabs (ASCII 9), and CRLFs.
497
498
499
500 Zimmerman [Page 9]
501
502 RFC 1288 Finger December 1991
503
504
505 This is to protect against people playing with terminal escape codes,
506 changing other peoples' X window names, or committing other dastardly
507 or confusing deeds. Two separate user options SHOULD be considered
508 to modify this behavior, so that users may choose to view
509 international or control characters:
510
511 - one to allow all characters less than ASCII 32
512
513 - another to allow all characters greater than ASCII 126
514
515 For environments that live and breathe international data, the system
516 administrator SHOULD be given a mechanism to enable the latter option
517 by default for all users on a particular system. This can be done
518 via a global environment variable or similar mechanism.
519
520 4. Examples
521
522 4.1. Example with a null command line ({C})
523
524 Site: elbereth.rutgers.edu
525 Command line: <CRLF>
526
527 Login Name TTY Idle When Office
528 rinehart Mark J. Rinehart p0 1:11 Mon 12:15 019 Hill x3166
529 greenfie Stephen J. Greenfiel p1 Mon 15:46 542 Hill x3074
530 rapatel Rocky - Rakesh Patel p3 4d Thu 00:58 028 Hill x2287
531 pleasant Mel Pleasant p4 3d Thu 21:32 019 Hill 908-932-
532 dphillip Dave Phillips p5 021: Sun 18:24 265 Hill x3792
533 dmk David Katinsky p6 2d Thu 14:11 028 Hill x2492
534 cherniss Cary Cherniss p7 5 Mon 15:42 127 Psychol x2008
535 harnaga Doug Harnaga p8 2:01 Mon 10:15 055 Hill x2351
536 brisco Thomas P. Brisco pe 2:09 Mon 13:37 h055 x2351
537 laidlaw Angus Laidlaw q0 1:55 Mon 11:26 E313C 648-5592
538 cje Chris Jarocha-Ernst q1 8 Mon 13:43 259 Hill x2413
539
540 4.2. Example with name specified ({U}{C})
541
542 Site: dimacs.rutgers.edu
543 Command line: pirmann<CRLF>
544 Login name: pirmann In real life: David Pirmann
545 Office: 016 Hill, x2443 Home phone: 989-8482
546 Directory: /dimacs/u1/pirmann Shell: /bin/tcsh
547 Last login Sat Jun 23 10:47 on ttyp0 from romulus.rutgers.
548 No unread mail
549 Project:
550 Plan:
551 Work Schedule, Summer 1990
552 Rutgers LCSR Operations, 908-932-2443
553
554
555
556 Zimmerman [Page 10]
557
558 RFC 1288 Finger December 1991
559
560
561 Monday 5pm - 12am
562 Tuesday 5pm - 12am
563 Wednesday 9am - 5pm
564 Thursday 9am - 5pm
565 Saturday 9am - 5pm
566
567 larf larf hoo hoo
568
569 4.3. Example with ambiguous name specified ({U}{C})
570
571 Site: elbereth.rutgers.edu
572 Command line: ron<CRLF>
573 Login name: spinner In real life: Ron Spinner
574 Office: Ops Cubby, x2443 Home phone: 463-7358
575 Directory: /u1/spinner Shell: /bin/tcsh
576 Last login Mon May 7 16:38 on ttyq7
577 Plan:
578 ught i
579 ca n
580 m a
581 ' ... t
582 I . . i
583 ! m
584 ! ! e
585 p !pool
586 l
587 e
588 H
589
590 Login name: surak In real life: Ron Surak
591 Office: 000 OMB Dou, x9256
592 Directory: /u2/surak Shell: /bin/tcsh
593 Last login Fri Jul 27 09:55 on ttyq3
594 No Plan.
595
596 Login name: etter In real life: Ron Etter
597 Directory: /u2/etter Shell: /bin/tcsh
598 Never logged in.
599 No Plan.
600
601 4.4. Example of query type {Q2} ({U}{H}{H}{C})
602
603 Site: dimacs.rutgers.edu
604 Command line: hedrick@math.rutgers.edu@pilot.njin.net<CRLF>
605 [pilot.njin.net]
606 [math.rutgers.edu]
607 Login name: hedrick In real life: Charles Hedrick
608 Office: 484 Hill, x3088
609
610
611
612 Zimmerman [Page 11]
613
614 RFC 1288 Finger December 1991
615
616
617 Directory: /math/u2/hedrick Shell: /bin/tcsh
618 Last login Sun Jun 24 00:08 on ttyp1 from monster-gw.rutge
619 No unread mail
620 No Plan.
621
622 5. Acknowledgments
623
624 Thanks to everyone in the Internet Engineering Task Force for their
625 comments. Special thanks to Steve Crocker for his security
626 recommendations and prose.
627
628 6. Security Considerations
629
630 Security issues are discussed in Section 3.
631
632 7. Author's Address
633
634 David Paul Zimmerman
635 Center for Discrete Mathematics and
636 Theoretical Computer Science (DIMACS)
637 Rutgers University
638 P.O. Box 1179
639 Piscataway, NJ 08855-1179
640
641 Phone: (908)932-4592
642
643 EMail: dpz@dimacs.rutgers.edu
644
645
646 Zimmerman [Page 12]