Difference between revisions of "RFC1408"

From RFC-Wiki
imported>Admin
(Created page with " Network Working Group D. Borman, EditorRequest for Comments: 1408 Cray Research, Inc. ...")
 
Line 4: Line 4:
  
  
 
+
Network Working Group                                  D. Borman, Editor
Network Working Group                                  D. Borman, EditorRequest for Comments: 1408                          Cray Research, Inc.                                                         January 1993
+
Request for Comments: 1408                          Cray Research, Inc.
 +
                                                        January 1993
  
 
                     Telnet Environment Option
 
                     Telnet Environment Option
 
Status of this Memo
 
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internetcommunity, and requests discussion and suggestions for improvements.Please refer to the current edition of the "IAB Official ProtocolStandards" for the standardization state and status of this protocol.Distribution of this memo is unlimited.
+
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
 
Abstract
 
 
This document specifies a mechanism for passing environment
 
This document specifies a mechanism for passing environment
 
information between a telnet client and server.  Use of this
 
information between a telnet client and server.  Use of this
 
mechanism enables a telnet user to propagate configuration
 
mechanism enables a telnet user to propagate configuration
 
information to a remote host when connecting.
 
information to a remote host when connecting.
 
+
== Command Names and Codes ==
== Command Names and Codes ==
 
 
 
 
   ENVIRON        36
 
   ENVIRON        36
 
       IS              0
 
       IS              0
 
       SEND            1
 
       SEND            1
 
       INFO            2
 
       INFO            2
 
 
       VAR              0
 
       VAR              0
 
       VALUE            1
 
       VALUE            1
 
       ESC              2
 
       ESC              2
 
       USERVAR          3
 
       USERVAR          3
 
+
== Command Meanings ==
== Command Meanings ==
 
 
 
  
 
IAC WILL ENVIRON
 
IAC WILL ENVIRON
 
 
   The sender of this command is willing to send environment
 
   The sender of this command is willing to send environment
 
   variables.
 
   variables.
 +
IAC WONT ENVIRON
 +
  The sender of this command refuses to send environment variables.
  
IAC WONT ENVIRON
 
  
  The sender of this command refuses to send environment variables.
 
  
  
Line 49: Line 47:
  
 
IAC DO ENVIRON
 
IAC DO ENVIRON
 
 
   The sender of this command is willing to receive environment
 
   The sender of this command is willing to receive environment
 
   variables.
 
   variables.
 
 
IAC DONT ENVIRON
 
IAC DONT ENVIRON
 
 
   The sender of this command refuses to accept environment
 
   The sender of this command refuses to accept environment
 
   variables.
 
   variables.
 
 
IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
 
IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE
 
 
   The sender of this command requests that the remote side send its
 
   The sender of this command requests that the remote side send its
 
   environment variables.  The "type" may be either VAR or USERVAR,
 
   environment variables.  The "type" may be either VAR or USERVAR,
Line 70: Line 63:
 
   (well known or user defined)  in the default environment should be
 
   (well known or user defined)  in the default environment should be
 
   sent.
 
   sent.
 
 
IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
 
IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
 
 
The sender of this command is sending environment variables.  This
 
The sender of this command is sending environment variables.  This
 
   command is sent in response to a SEND request.  Only the side that
 
   command is sent in response to a SEND request.  Only the side that
Line 89: Line 80:
 
   IAC.  If a variable or a value contains a VAR, it must be sent as
 
   IAC.  If a variable or a value contains a VAR, it must be sent as
 
   ESC VAR.
 
   ESC VAR.
 
 
   If a variable or a value contains a USERVAR, it must be sent as
 
   If a variable or a value contains a USERVAR, it must be sent as
 
   ESC USERVAR.  If a variable or a value contains a VALUE, it must
 
   ESC USERVAR.  If a variable or a value contains a VALUE, it must
 
   be sent as ESC VALUE.  If a variable or a value contains an ESC,
 
   be sent as ESC VALUE.  If a variable or a value contains an ESC,
 
   it must be sent as ESC ESC.
 
   it must be sent as ESC ESC.
 +
 +
  
  
Line 102: Line 94:
  
 
IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
 
IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [
 
 
The sender of this command is sending information about environment
 
The sender of this command is sending information about environment
 
   variables that have changed.  It is identical to the IS command,
 
   variables that have changed.  It is identical to the IS command,
Line 111: Line 102:
 
   changes in environment variables, and may be spontaneously
 
   changes in environment variables, and may be spontaneously
 
   generated.
 
   generated.
 
+
== Default Specification ==
== Default Specification ==
 
 
 
 
The default specification for this option is
 
The default specification for this option is
 
 
   WONT ENVIRON
 
   WONT ENVIRON
 
   DONT ENVIRON
 
   DONT ENVIRON
 
 
meaning there will not be any exchange of environment information.
 
meaning there will not be any exchange of environment information.
 
+
== Motivation ==
== Motivation ==
 
 
 
 
Many operating systems have startup information and environment
 
Many operating systems have startup information and environment
 
variables that contain information that should be propagated to
 
variables that contain information that should be propagated to
Line 130: Line 115:
 
that the Telnet session itself doesn't really need to know about,
 
that the Telnet session itself doesn't really need to know about,
 
this generic information option can be used.
 
this generic information option can be used.
 
+
== Well Known Variables ==
== Well Known Variables ==
 
 
 
 
USER        This variable is used to transmit the user or account
 
USER        This variable is used to transmit the user or account
 
             name that the client wishes to log into on the remote
 
             name that the client wishes to log into on the remote
 
             system.  The format of the value the USER variable is
 
             system.  The format of the value the USER variable is
 
             system dependent, as determined by the remote system.
 
             system dependent, as determined by the remote system.
 
 
JOB        This variable is used to transmit the job ID that the
 
JOB        This variable is used to transmit the job ID that the
 
             client wishes to use when logging into the remote system.
 
             client wishes to use when logging into the remote system.
 
             The format of the value the JOB variable is system
 
             The format of the value the JOB variable is system
 
             dependent, as determined by the remote system.
 
             dependent, as determined by the remote system.
 
 
ACCT        This variable is used to transmit the account ID that the
 
ACCT        This variable is used to transmit the account ID that the
 
             client wishes to use when logging into the remote system.
 
             client wishes to use when logging into the remote system.
 
             The format of the value the ACCT variable is system
 
             The format of the value the ACCT variable is system
 
             dependent, as determined by the remote system.
 
             dependent, as determined by the remote system.
 +
 +
  
  
Line 158: Line 141:
 
             exist a standard way of naming a printer on a network,
 
             exist a standard way of naming a printer on a network,
 
             the format of this variable is currently undefined.
 
             the format of this variable is currently undefined.
 
 
SYSTEMTYPE  This is used to transmit the type of operating system on
 
SYSTEMTYPE  This is used to transmit the type of operating system on
 
             the system that sends this variable.  It value is
 
             the system that sends this variable.  It value is
Line 165: Line 147:
 
             first word one of the system names listed in the
 
             first word one of the system names listed in the
 
             current version of the Assigned Numbers document [3].
 
             current version of the Assigned Numbers document [3].
 
 
DISPLAY    This variable is used to transmit the X display location
 
DISPLAY    This variable is used to transmit the X display location
 
             of the client.  The format for the value of the DISPLAY
 
             of the client.  The format for the value of the DISPLAY
Line 176: Line 157:
 
             contain conflicting information, the most recently
 
             contain conflicting information, the most recently
 
             received information received should be used.
 
             received information received should be used.
 
 
Because it is impossible to anticipate all variables that users may
 
Because it is impossible to anticipate all variables that users may
 
wish to exchange, the USERVAR type is provided to allow users to
 
wish to exchange, the USERVAR type is provided to allow users to
Line 185: Line 165:
 
of distrust.  The results of a name-space collision between a well-
 
of distrust.  The results of a name-space collision between a well-
 
known and a user variable are implementation specific.
 
known and a user variable are implementation specific.
 
+
== Implementation Rules ==
== Implementation Rules ==
 
 
 
 
WILL and DO are used only at the beginning of the connection to
 
WILL and DO are used only at the beginning of the connection to
 
obtain and grant permission for future negotiations.
 
obtain and grant permission for future negotiations.
 
 
Once the two hosts have exchanged a WILL and a DO, the sender of the
 
Once the two hosts have exchanged a WILL and a DO, the sender of the
 
DO ENVIRON is free to request that environment variables be sent.
 
DO ENVIRON is free to request that environment variables be sent.
Line 202: Line 179:
 
information at process creation, so the information is needed before
 
information at process creation, so the information is needed before
 
the user logs in.  In this section, anything that is in quotes is
 
the user logs in.  In this section, anything that is in quotes is
 +
 +
  
  
Line 209: Line 188:
 
shorthand for a string of ASCII values.  For example, "joe" means the
 
shorthand for a string of ASCII values.  For example, "joe" means the
 
three octet sequence (in decimal) 106 111 101.
 
three octet sequence (in decimal) 106 111 101.
 
 
The receiving host is not required to put all variables that it
 
The receiving host is not required to put all variables that it
 
receives into the environment.  For example, if the client should
 
receives into the environment.  For example, if the client should
Line 225: Line 203:
 
the suggested method of implementation, because it allows the user
 
the suggested method of implementation, because it allows the user
 
the most flexibility.
 
the most flexibility.
 
 
The following is an example of use of the option:
 
The following is an example of use of the option:
 
 
     Host1                            Host2
 
     Host1                            Host2
 
     IAC DO ENVIRON
 
     IAC DO ENVIRON
Line 246: Line 222:
 
                                     USERVAR "SHELL" VALUE "/bin/csh"
 
                                     USERVAR "SHELL" VALUE "/bin/csh"
 
                                     IAC SE
 
                                     IAC SE
 
 
It is legal for a client to respond with an empty environment (no
 
It is legal for a client to respond with an empty environment (no
 
data between the IAC SB and IAC SE) when no well-defined or user
 
data between the IAC SB and IAC SE) when no well-defined or user
 
variables are currently defined.  For example:
 
variables are currently defined.  For example:
 +
  IAC SB ENVIRON IS IAC SE
 +
  
  IAC SB ENVIRON IS IAC SE
 
  
  
Line 261: Line 237:
  
 
is a valid response to any of the following:
 
is a valid response to any of the following:
 
 
       IAC SB ENVIRON SEND IAC SE
 
       IAC SB ENVIRON SEND IAC SE
 
       IAC SB ENVIRON SEND VAR IAC SE
 
       IAC SB ENVIRON SEND VAR IAC SE
 
       IAC SB ENVIRON SEND USERVAR IAC SE
 
       IAC SB ENVIRON SEND USERVAR IAC SE
 
       IAC SB ENVIRON SEND VAR USERVAR IAC SE
 
       IAC SB ENVIRON SEND VAR USERVAR IAC SE
 
 
(The last example is equivalent to the first...)
 
(The last example is equivalent to the first...)
 
 
It is expected that any implementation that supports the Telnet
 
It is expected that any implementation that supports the Telnet
 
ENVIRON option will support all of this specification.
 
ENVIRON option will support all of this specification.
 
+
== Security Concerns ==
== Security Concerns ==
 
 
 
 
It is important for an implementor of the ENVIRON option to
 
It is important for an implementor of the ENVIRON option to
 
understand the interaction of setting options and the
 
understand the interaction of setting options and the
Line 281: Line 252:
 
variable to be changed that allows an intruder to circumvent or
 
variable to be changed that allows an intruder to circumvent or
 
compromise the login/authentication program itself.
 
compromise the login/authentication program itself.
 +
==  References ==
 +
[1] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP
 +
    Software, Inc., February 1989.
 +
[2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD
 +
    9, RFC 959, USC/Information Sciences Institute, October 1985.
 +
[3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
 +
    USC/Information Sciences Institute, July 1992.
 +
[4] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie
 +
    Mellon University, March 1989.
 +
Security Considerations
 +
Security issues are discussed in Section 7.
 +
  
== References ==
 
  
[1] VanBokkelen, J., "Telnet Terminal-Type Option", [[RFC1091|RFC 1091]], FTP    Software, Inc., February 1989.
 
[2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD    9, [[RFC959|RFC 959]], USC/Information Sciences Institute, October 1985.
 
[3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, [[RFC1340|RFC 1340]],    USC/Information Sciences Institute, July 1992.
 
[4] Marcy, G., "Telnet X Display Location Option", [[RFC1096|RFC 1096]], Carnegie    Mellon University, March 1989.
 
Security Considerations
 
Security issues are discussed in Section 7.
 
  
  
Line 304: Line 280:
  
 
Author's Address
 
Author's Address
David A. Borman, EditorCray Research, Inc.655F Lone Oak DriveEagan, MN 55123
+
David A. Borman, Editor
Phone: (612) 452-6650EMail: [email protected]
+
Cray Research, Inc.
 +
655F Lone Oak Drive
 +
Eagan, MN 55123
 +
Phone: (612) 452-6650
 +
 
Mailing List: [email protected]
 
Mailing List: [email protected]
 
Chair's Address
 
Chair's Address
 
The working group can be contacted via the current chair:
 
The working group can be contacted via the current chair:
Steve AlexanderINTERACTIVE Systems Corporation1901 North Naper BoulevardNaperville, IL 60563-8895
+
Steve Alexander
Phone: (708) 505-9100 x256EMail: [email protected]
+
INTERACTIVE Systems Corporation
 +
1901 North Naper Boulevard
 +
Naperville, IL 60563-8895
 +
Phone: (708) 505-9100 x256
 +

Revision as of 07:16, 23 September 2020



Network Working Group D. Borman, Editor Request for Comments: 1408 Cray Research, Inc.

                                                        January 1993
                   Telnet Environment Option

Status of this Memo 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 document specifies a mechanism for passing environment information between a telnet client and server. Use of this mechanism enables a telnet user to propagate configuration information to a remote host when connecting.

Command Names and Codes

  ENVIRON         36
      IS               0
      SEND             1
      INFO             2
      VAR              0
      VALUE            1
      ESC              2
      USERVAR          3

Command Meanings

IAC WILL ENVIRON

  The sender of this command is willing to send environment
  variables.

IAC WONT ENVIRON

  The sender of this command refuses to send environment variables.






IAC DO ENVIRON

  The sender of this command is willing to receive environment
  variables.

IAC DONT ENVIRON

  The sender of this command refuses to accept environment
  variables.

IAC SB ENVIRON SEND [ type ... [ type ... [ ... ] ] ] IAC SE

  The sender of this command requests that the remote side send its
  environment variables.  The "type" may be either VAR or USERVAR,
  to indicate either well known or user variable names.  Only the
  side that is DO ENVIRON may initiate a SEND command.  If a list of
  variables is specified, then only those variables should be sent.
  If no list is specified, then the default environment, of both
  well known and user defined variables, should be sent.  If one of
  the variables has no name, then all the variables of that type
  (well known or user defined)  in the default environment should be
  sent.

IAC SB ENVIRON IS type ... [ VALUE ... ] [ type ... [ VALUE ... ] [ The sender of this command is sending environment variables. This

  command is sent in response to a SEND request.  Only the side that
  is WILL ENVIRON may send an IS command.  The "type"/VALUE pairs
  must be returned in the same order as the SEND request specified
  them, and there must be a response for each "type ..." explicitly
  requested.  The "type" will be VAR or USERVAR.  Multiple
  environment variables may be sent.  The characters following a
  "type" up to the next "type" or VALUE specify the variable name.
  The characters following a VALUE up to the next "type" specify the
  value of the variable.  If a "type" is not followed by a VALUE
  (e.g., by another VAR, USERVAR, or IAC SE) then that variable is
  undefined.  If a VALUE is immediately followed by a "type" or IAC,
  then the variable is defined, but has no value.  If an IAC is
  contained between the IS and the IAC SE, it must be sent as IAC
  IAC.  If a variable or a value contains a VAR, it must be sent as
  ESC VAR.
  If a variable or a value contains a USERVAR, it must be sent as
  ESC USERVAR.  If a variable or a value contains a VALUE, it must
  be sent as ESC VALUE.  If a variable or a value contains an ESC,
  it must be sent as ESC ESC.





IAC SB ENVIRON INFO type ... [ VALUE ... ] [ type ... [ VALUE ... ] [ The sender of this command is sending information about environment

  variables that have changed.  It is identical to the IS command,
  except that the command is INFO instead of IS.  Only the side that
  is WILL ENVIRON may send an INFO command.  The INFO command is not
  to be used to send initial information; the SEND/IS sequence is to
  be used for that.  The INFO command is to be used to propagate
  changes in environment variables, and may be spontaneously
  generated.

Default Specification

The default specification for this option is

  WONT ENVIRON
  DONT ENVIRON

meaning there will not be any exchange of environment information.

Motivation

Many operating systems have startup information and environment variables that contain information that should be propagated to remote machines when Telnet connections are established. Rather than create a new Telnet option each time someone comes up with some new information that they need propagated through a Telnet session, but that the Telnet session itself doesn't really need to know about, this generic information option can be used.

Well Known Variables

USER This variable is used to transmit the user or account

           name that the client wishes to log into on the remote
           system.  The format of the value the USER variable is
           system dependent, as determined by the remote system.

JOB This variable is used to transmit the job ID that the

           client wishes to use when logging into the remote system.
           The format of the value the JOB variable is system
           dependent, as determined by the remote system.

ACCT This variable is used to transmit the account ID that the

           client wishes to use when logging into the remote system.
           The format of the value the ACCT variable is system
           dependent, as determined by the remote system.





PRINTER This variable is used to identify the default location

           for printer output.  Because there does not currently
           exist a standard way of naming a printer on a network,
           the format of this variable is currently undefined.

SYSTEMTYPE This is used to transmit the type of operating system on

           the system that sends this variable.  It value is
           identical to the value of the SYSTEM (SYST) command in
           FTP [2].  The format of the value shall have as its
           first word one of the system names listed in the
           current version of the Assigned Numbers document [3].

DISPLAY This variable is used to transmit the X display location

           of the client.  The format for the value of the DISPLAY
           variable is:
              <host>:<dispnum>[.<screennum>]
           This information is identical to the information passed
           using the Telnet X-DISPLAY-LOCATION option.  If both the
           DISPLAY environment variable, and the
           X-DISPLAY-LOCATION option[4] are received, and they
           contain conflicting information, the most recently
           received information received should be used.

Because it is impossible to anticipate all variables that users may wish to exchange, the USERVAR type is provided to allow users to transmit arbitrary variable/value pairs. The use of an additional type allows implementations to distinguish between values derived by the remote host software and values supplied by the user. Paranoid implementations will most likely treat both types with an equal level of distrust. The results of a name-space collision between a well- known and a user variable are implementation specific.

Implementation Rules

WILL and DO are used only at the beginning of the connection to obtain and grant permission for future negotiations. Once the two hosts have exchanged a WILL and a DO, the sender of the DO ENVIRON is free to request that environment variables be sent. Only the sender of the DO may send requests (IAC SB ENVIRON SEND IAC SE) and only the sender of the WILL may transmit actual environment information (via the IAC SB ENVIRON IS ... IAC SE command). Though this option may be used at anytime throughout the life of the telnet connection, the exchange of environment information will usually happen at the startup of the connection. This is because many operating systems only have mechanisms for propagating environment information at process creation, so the information is needed before the user logs in. In this section, anything that is in quotes is




shorthand for a string of ASCII values. For example, "joe" means the three octet sequence (in decimal) 106 111 101. The receiving host is not required to put all variables that it receives into the environment. For example, if the client should send across USERVAR "TERM" VALUE "xterm" as an environment variable, and the TERMINAL-TYPE [1] option has already been used to determine the terminal type, the server may safely ignore the TERM variable. Also, some startup information may be used in other ways; for example, the values for "USER", "ACCT" and "PROJ" values might be used to decide which account to log into, and might never be put into the users environment. In general, if the server has already determined the value of an environment variable by some more accurate means, or if it does not understand a variable name, it may ignore the value sent in the ENVIRON option. The server may also prefer to just put all unknown information into the users environment. This is the suggested method of implementation, because it allows the user the most flexibility. The following is an example of use of the option:

   Host1                            Host2
   IAC DO ENVIRON
                                    IAC WILL ENVIRON
   [ Host1 is now free to request environment information ]
   IAC SB ENVIRON SEND VAR "USER"
   VAR "ACCT" VAR USERVAR IAC SE
   [ The server has now explicitly asked for the USER and ACCT
     variables, the default set of well known environment variables,
     and the default set of user defined variables.  Note that the
     client includes the USER information twice; once because it was
     explicitly asked for, and once because it is part of the
     default environment.  ]
                                    IAC SB ENVIRON IS VAR "USER"
                                    VALUE "joe" VAR "ACCT" VALUE
                                    "kernel" VAR "USER" VALUE "joe"
                                    VAR "DISPLAY" VALUE "foo:0.0"
                                    USERVAR "SHELL" VALUE "/bin/csh"
                                    IAC SE

It is legal for a client to respond with an empty environment (no data between the IAC SB and IAC SE) when no well-defined or user variables are currently defined. For example:

  IAC SB ENVIRON IS IAC SE






is a valid response to any of the following:

     IAC SB ENVIRON SEND IAC SE
     IAC SB ENVIRON SEND VAR IAC SE
     IAC SB ENVIRON SEND USERVAR IAC SE
     IAC SB ENVIRON SEND VAR USERVAR IAC SE

(The last example is equivalent to the first...) It is expected that any implementation that supports the Telnet ENVIRON option will support all of this specification.

Security Concerns

It is important for an implementor of the ENVIRON option to understand the interaction of setting options and the login/authentication process. Specifically careful analysis should be done to determine which variables are "safe" to set prior to having the client login. An example of a bad choice would be permitting a variable to be changed that allows an intruder to circumvent or compromise the login/authentication program itself.

References

[1] VanBokkelen, J., "Telnet Terminal-Type Option", RFC 1091, FTP

   Software, Inc., February 1989.

[2] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD

   9, RFC 959, USC/Information Sciences Institute, October 1985.

[3] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1340,

   USC/Information Sciences Institute, July 1992.

[4] Marcy, G., "Telnet X Display Location Option", RFC 1096, Carnegie

   Mellon University, March 1989.

Security Considerations Security issues are discussed in Section 7.









Author's Address David A. Borman, Editor Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55123 Phone: (612) 452-6650 EMail: [email protected] Mailing List: [email protected] Chair's Address The working group can be contacted via the current chair: Steve Alexander INTERACTIVE Systems Corporation 1901 North Naper Boulevard Naperville, IL 60563-8895 Phone: (708) 505-9100 x256 EMail: [email protected]