rfc2877.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,533 行 · 第 1/5 页

   RFC 1572 defines 6 standard VAR's: USER, JOB, ACCT, PRINTER,
   SYSTEMTYPE, and DISPLAY.  The USER standard VAR will hold the value
   of the AS/400 user profile name to be used in auto-signon requests.
   The Telnet server will make no direct use of the additional 5 VAR's,
   nor are any of them required to be sent.  All standard VAR's and
   their values that are received by the Telnet server will be placed in
   a buffer, along with any USERVAR's received (described below), and
   made available to a registered initialization exit program to be used
   for any purpose desired.

   There are some reasons you may want to send NEW-ENVIRON negotiations
   prior to TERMINAL-TYPE negotiations.  With AS/400 TELNET server,
   several virtual device modes can be negotiated: 1) VTxxx device 2)
   3270 device 3) 5250 device (includes Network Station).  The virtual
   device mode selected depends on the TERMINAL-TYPE negotiated plus any
   other TELNET option negotiations necessary to support those modes.
   The AS/400 TELNET server will create the desired virtual device at
   the first opportunity it thinks it has all the requested attributes
   needed to create the device.  This can be as early as completion of
   the TERMINAL-TYPE negotiations.

   For the case of Transparent mode (5250 device), then the moment
   TERMINAL-TYPE, BINARY, and EOR options are negotiated the TELNET
   server will go create the virtual device.  Receiving any NEW-ENVIRON
   negotiations after these option negotiations are complete will result
   in the NEW-ENVIRON negotiations having no effect on device
   attributes, as the virtual device will have already been created.



Murphy, et al.               Informational                      [Page 6]

RFC 2877                5250 Telnet Enhancements               July 2000


   So, for Transparent mode, NEW-ENVIRON negotiations are effectively
   closed once EOR is negotiated, since EOR is generally the last option
   done.

   For other devices modes (such as VTxxx or 3270), you cannot be sure
   when the AS/400 TELNET server thinks it has all the attributes to
   create the device.  Recall that NEW-ENVIRON negotiations are
   optional, and therefore the AS/400 TELNET server need not wait for
   any NEW-ENVIRON options prior to creating the virtual device.  It is
   in the clients best interest to send NEW-ENVIRON negotiations as soon
   as possible, preferably before TERMINAL-TYPE is negotiated.  That
   way, the client can be sure the requested attributes were received
   before the virtual device is created.

4. Enhanced Display Emulation Support

   RFC 1572 style USERVAR variables have been defined to allow a
   compliant Telnet client more control over the Telnet server virtual
   device on the AS/400.  These USERVAR's allow the client Telnet to
   create or select a previously created virtual device.  If the virtual
   device does not exist and must be created, then the USERVAR variables
   are used to create and initialize the device attributes.  If the
   virtual device already exists, the device attributes are modified.

   The USERVAR's defined to accomplish this are:

   USERVAR    VALUE              EXAMPLE           DESCRIPTION
   --------   ----------------   ----------------  -------------------
   DEVNAME    us-ascii char(x)   MYDEVICE07        Display device name
   KBDTYPE    us-ascii char(3)   USB               Keyboard type
   CODEPAGE   us-ascii char(y)   437               Code page
   CHARSET    us-ascii char(y)   1212              Character set

   x - up to a maximum of 10 characters
   y - up to a maximum of 5 characters

   For a description of the KBDTYPE, CODEPAGE and CHARSET parameters and
   their permissible values, refer to Chapter 8 in the Communications
   Configuration Reference [5] and also to Appendix C in National
   Language Support [16].

   The CODEPAGE and CHARSET USERVAR's must be associated with a KBDTYPE
   USERVAR.  If either CODEPAGE or CHARSET are sent without KBDTYPE,
   they will default to system values.  A default value for KBDTYPE can
   be sent to force CODEPAGE and CHARSET values to be used.






Murphy, et al.               Informational                      [Page 7]

RFC 2877                5250 Telnet Enhancements               July 2000


   AS/400 system objects such as device names, user profiles, clear-text
   passwords, programs, libraries, etc. are required to be specified in
   English Upper Case (EUC).  This includes:

     Any letter (A-Z), any number (0-9), special characters (# $ _ @)

   Therefore, where us-ascii is specified for VAR or USERVAR values, it
   is recommended that upper-cased ASCII values be sent, which will be
   converted to EBCDIC by the Telnet server.

   A special case occurs for encrypted passwords (described in the next
   section), where both the initial password and user profile used to
   build the encrypted password must be EBCDIC English Upper Case, in
   order to be properly authenticated by the Telnet server.

5. Enhanced Display Auto-Signon and Password Encryption

   Several 5250 Telnet server specific USERVAR's will be defined.  One
   will carry a random seed to be used in Data Encryption Standard (DES)
   password encryption, and another will carry the encrypted copy of the
   password.  This would use the same 7-step DES-based password
   substitution scheme as APPC and Client Access.  For a description of
   DES encryption, refer to Federal Information Processing Standards
   Publications (FIPS) 46-2 [17] and 81 [18], which can be found at the
   Federal Information Processing Standards Publications link:

   http://www.itl.nist.gov/div897/pubs/by-num.htm

   For a description of the 7-step password substitution scheme, refer
   to these IBM Customer Support FTP Server links:

   ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps
   ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.ps.Z
   ftp://ftp.networking.ibm.com/pub/standards/ciw/sig/sec/pwsubciw.zip

   If encrypted password exchange is not required, clear-text password
   exchange is permitted using the same USERVAR's defined for
   encryption.  For this case, the random client seed should be set to
   either an empty value (RFC 1572 preferred method) or to hexadecimal
   zeros to indicate the password is not encrypted, but is clear-text.

   It should be noted that security of clear-text password exchange
   cannot be guaranteed unless the network is physically protected or a
   trusted network (such as an intranet).  If your network is vulnerable
   to IP address spoofing or directly connected to the Internet, you
   should engage in encrypted password exchange to validate a clients
   identity.




Murphy, et al.               Informational                      [Page 8]

RFC 2877                5250 Telnet Enhancements               July 2000


   Additional VAR's and USERVAR's have also been defined to allow an
   auto-signon user greater control over their startup environment,
   similar to what is supported using the Open Virtual Terminal
   (QTVOPNVT) API [3].

   The standard VAR's supported to accomplish this are:

   VAR        VALUE              EXAMPLE           DESCRIPTION
   --------   ----------------   ----------------  -------------------
   USER       us-ascii char(x)   USERXYZ           User profile name

   x - up to a maximum of 10 characters

   The custom USERVAR's defined to accomplish this are:

   USERVAR       VALUE              EXAMPLE           DESCRIPTION
   --------      ----------------   ----------------  -------------------
   IBMRSEED      binary(8)          8-byte hex field  Random client seed
   IBMSUBSPW     binary(10)         10-byte hex field Substitute password
   IBMCURLIB     us-ascii char(x)   QGPL              Current library
   IBMIMENU      us-ascii char(x)   MAIN              Initial menu
   IBMPROGRAM    us-ascii char(x)   QCMD              Program to call

   x - up to a maximum of 10 characters

   In order to communicate the server random seed value to the client,
   the server will request a USERVAR name made up of a fixed part (the 8
   characters "IBMRSEED" immediately followed by an 8-byte hexadecimal
   variable part, which is the server random seed.  The client generates
   its own 8-byte random seed value, and uses both seeds to encrypt the
   password.  Both the encrypted password and the client random seed
   value are then sent to the server for authentication.  RFC 1572 rules
   will need to be adhered to when transmitting the client random seed
   and substituted password values to the server.  Specifically, since a
   typical environment string is a variable length hexadecimal field,
   the hexadecimal fields are required to be escaped and/or byte stuffed
   according to the RFC 854 [8], where any single byte could be mis-
   construed as a Telnet IAC or other Telnet option negotiation control
   character.  The client must escape and/or byte stuff any bytes which
   could be seen as a RFC 1572 [13] option, specifically VAR, VALUE, ESC
   and USERVAR.










Murphy, et al.               Informational                      [Page 9]

RFC 2877                5250 Telnet Enhancements               July 2000


   The following illustrates the encrypted case:

   AS/400 Telnet server             Enhanced Telnet client
   --------------------------       -------------------------------
   IAC DO NEW-ENVIRON          -->
                               <--  IAC WILL NEW-ENVIRON
   IAC SB NEW-ENVIRON SEND
   USERVAR "IBMRSEEDxxxxxxxx"
   USERVAR "IBMSUBSPW"
   VAR USERVAR IAC SE          -->
                                    IAC SB NEW-ENVIRON IS
                                    VAR "USER" VALUE "DUMMYUSR"
                                    USERVAR "IBMRSEED" VALUE "yyyyyyyy"
                                    USERVAR "IBMSUBSPW" VALUE "zzzzzzzz"
                               <--  IAC SE
                                .
                                .
   (other negotiations)         .

   In this example, "xxxxxxxx" is an 8-byte hexadecimal random server
   seed, "yyyyyyyy" is an 8-byte hexadecimal random client seed and
   "zzzzzzzz" is an 8-byte hexadecimal encrypted password.  If the
   password is not valid, then the sign-on panel is displayed.  If the
   password is expired, then the Change Password panel is displayed.

   Actual bytes transmitted in the above example are shown in hex below,
   where the server seed is "7D3E488F18080404", the client seed is
   "4E4142334E414233" and the encrypted password is "DFB0402F22ABA3BA".
   The user profile used to generate the encrypted password is
   "44554D4D59555352" (DUMMYUSR), with a clear-text password of
   "44554D4D595057" (DUMMYPW).

   AS/400 Telnet server             Enhanced Telnet client
   --------------------------       -------------------------
   FF FD 27                    -->
                               <--  FF FB 27
   FF FA 27 01 03 49 42 4D
   52 53 45 45 44 7D 3E 48
   8F 18 08 04 04 03 49 42
   4D 53 55 42 53 50 57 03
   00 FF F0                    -->
                                    FF FA 27 00 00 55 53 45
                                    52 01 44 55 4D 4D 59 55
                                    53 52 03 49 42 4D 52 53
                                    45 45 44 01 4E 41 42 33
                                    4E 41 42 33 03 49 42 4D





Murphy, et al.               Informational                     [Page 10]

RFC 2877                5250 Telnet Enhancements               July 2000


                                    53 55 42 53 50 57 01 DF
                                    B0 40 2F 22 AB A3 BA FF
                               <--  F0

   The following illustrates the clear-text case:

   AS/400 Telnet server             Enhanced Telnet client
   --------------------------       -------------------------
   IAC DO NEW-ENVIRON          -->
                               <--  IAC WILL NEW-ENVIRON
   IAC SB NEW-ENVIRON SEND
   USERVAR "IBMRSEEDxxxxxxxx"
   USERVAR "IBMSUBSPW"
   VAR USERVAR IAC SE          -->
                                    IAC SB NEW-ENVIRON IS
                                    VAR "USER" VALUE "DUMMYUSR"
                                    USERVAR "IBMRSEED" VALUE
                                    USERVAR "IBMSUBSPW" VALUE "yyyyyyyy"
                               <--  IAC SE
                                .
                                .
   (other negotiations)         .

   In this example, "xxxxxxxx" is an 8-byte hexadecimal random server
   seed, "yyyyyyyyyy" is a 10-byte us-ascii client clear-text password.
   If the password has expired, then the sign-on panel is displayed.

   Actual bytes transmitted in the above example are shown in hex below,
   where the server seed is "7D3E488F18080404", the client seed is empty
   and the clear-text password is "44554D4D595057" (DUMMYPW).  The user
   profile used is "44554D4D59555352" (DUMMYUSR).

   AS/400 Telnet server             Enhanced Telnet client
   --------------------------       -------------------------
   FF FD 27                    -->
                               <--  FF FB 27
   FF FA 27 01 03 49 42 4D
   52 53 45 45 44 7D 3E 48
   8F 18 08 04 04 03 49 42
   4D 53 55 42 53 50 57 03
   00 FF F0                    -->
                                    FF FA 27 00 00 55 53 45
                                    52 01 44 55 4D 4D 59 55
                                    53 52 03 49 42 4D 52 53
                                    45 45 44 01 03 49 42 4D
                                    53 55 42 53 50 57 01 44
                               <--  55 4D 4D 59 50 57 FF F0