RFC1288

Network Working Group D. Zimmerman Request for Comments: 1288 Center for Discrete Mathematics and Obsoletes: RFCs 1196, 1194, 742 Theoretical Computer Science

                                                       December 1991

              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 RFC 1196. Table of Contents 1. Introduction ........................................... 2

 1.1.    Intent  ...............................................   2
 1.2.    History  ..............................................   3
 1.3.    Requirements  .........................................   3
 1.4.    Updates  ..............................................   3

2. Use of the protocol .................................... 4

 2.1.    Flow of events  .......................................   4
 2.2.    Data format  ..........................................   4
 2.3.    Query specifications  .................................   4
 2.4.    RUIP {Q2} behavior  ...................................   5
 2.5.    Expected RUIP response  ...............................   6
   2.5.1.  {C} query  ..........................................   6
   2.5.2.  {U}{C} query  .......................................   6
   2.5.3.  {U} ambiguity  ......................................   7
   2.5.4.  /W query token  .....................................   7

   2.5.5.  Vending machines  ...................................   7

3. Security ............................................... 7

 3.1.    Implementation security  ..............................   7
 3.2.    RUIP security  ........................................   8
   3.2.1.  {Q2} refusal  .......................................   8
   3.2.2.  {C} refusal  ........................................   8
   3.2.3.  Atomic discharge  ...................................   8
   3.2.4.  User information files  .............................   9
   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

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.

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". 1.4. Updates The differences of note between RFC 1196 and this memo are:

  o the optional /W switch in the Finger query specification was
    mistakenly placed at the end of the line.  The 4.3BSD Finger
    specifies it at the beginning, where this memo now also puts
    it.

  o the BNF in the Finger query specification was not clear on the
    treatment of blank space.  This memo is more exacting by
    including an explicit token for it.
  o The flow of events in a Finger connection is now better
    defined on the topic of the close of the Finger connection.

Use of the protocol

2.1. Flow of events Finger is based on the Transmission Control Protocol, using TCP port 79 decimal (117 octal). The local host opens a TCP connection to a remote host on the Finger port. An RUIP becomes available on the remote end of the connection to process the request. The local host sends the RUIP a one line query based upon the Finger query specification, and waits for the RUIP to respond. The RUIP receives and processes the query, returns an answer, then initiates the close of the connection. The local host receives the answer and the close signal, then proceeds closing its end of the connection. 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}    ::= [{W}|{W}{S}{U}]{C}
    {Q2}    ::= [{W}{S}][{U}]{H}{C}
    {U}     ::= username
    {H}     ::= @hostname | @hostname{H}
    {W}     ::= /W
    {S}     ::= <SP> | <SP>{S}
    {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". 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: Given that:

Host