rfc2877.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,533 行 · 第 1/5 页

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


5.1 Password Substitutes Processing

   Both APPC and Client Access use well-known DES encryption algorithms
   to create encrypted passwords.  A Network Station or Enhanced Client
   can generate compatible encrypted passwords if they follow these
   steps, details of which can be found in the Federal Information
   Processing Standards 46-2 [17].

   1. Padded_PW = Left justified user password padded to the right with
      '40'X to 8 bytes.

      The users password must be left justified in an 8 byte variable
      and padded to the right with '40'X up to an 8 byte length.  If the
      users password is 8 bytes in length, no padding would occur.  For
      computing password substitutes for passwords of length 9 and 10
      see section "Handling passwords of length 9 and 10" below.
      Passwords less than 1 byte or greater than 10 bytes in length are
      not valid.  Please note, if password is not in EBCDIC, it must be
      converted to EBCDIC uppercase.

   2. XOR_PW = Padded_PW xor '5555555555555555'X

      The padded password is Exclusive OR'ed with 8 bytes of '55'X.

   3. SHIFT_RESULT = XOR_PW << 1

      The entire 8 byte result is shifted 1 bit to the left; the
      leftmost bit value is discarded, and the rightmost bit value is
      cleared to 0.

   4. PW_TOKEN = DES_ECB_mode(SHIFT_RESULT,              /* key  */
                              userID_in_EBCDIC_uppercase /* data */ )

      This shifted result is used as key to the Data Encryption Standard
      (Federal Information Processing Standards 46-2 [17]) to encipher
      the user identifier.  When the user identifier is less than 8
      bytes, it is left justified in an 8 byte variable and padded to
      the right with '40'X.  When the user identifier is 9 or 10 bytes,
      it is first padded to the right with '40'X to a length of 10
      bytes.  Then bytes 9 and 10 are "folded" into bytes 1-8 using the
      following algorithm:

        Bit 0 is the high-order bit (i.e. has value of '80'X).

        Byte 1, bits 0 and 1 are replaced with byte 1, bits 0 and 1
        Exclusive OR'ed with byte 9, bits 0 and 1.
        Byte 2, bits 0 and 1 are replaced with byte 2, bits 0 and 1
        Exclusive OR'ed with byte 9, bits 2 and 3.



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


        Byte 3, bits 0 and 1 are replaced with byte 3, bits 0 and 1
        Exclusive OR'ed with byte 9, bits 4 and 5.
        Byte 4, bits 0 and 1 are replaced with byte 4, bits 0 and 1
        Exclusive OR'ed with byte 9, bits 6 and 7.
        Byte 5, bits 0 and 1 are replaced with byte 5, bits 0 and 1
        Exclusive OR'ed with byte 10, bits 0 and 1.
        Byte 6, bits 0 and 1 are replaced with byte 6, bits 0 and 1
        Exclusive OR'ed with byte 10, bits 2 and 3.
        Byte 7, bits 0 and 1 are replaced with byte 7, bits 0 and 1
        Exclusive OR'ed with byte 10, bits 4 and 5.
        Byte 8, bits 0 and 1 are replaced with byte 8, bits 0 and 1
        Exclusive OR'ed with byte 10, bits 6 and 7.

      User identifier greater than 10 bytes or less than 1 byte are not
      the result of this encryption id known as PW_TOKEN in the paper.

   5. Increment PWSEQs and store it.

      Each LU must maintain a pair of sequence numbers for ATTACHs sent
      and received on each session.  Each time an ATTACH is generated,
      (and password substitutes are in use on the session) the sending
      sequence number, PWSEQs, is incremented and saved for the next
      time.  Both values are set to zero at BIND time.  So the first use
      of PWSEQs has the value of 1, and increases by one with each use.
      A new field is added to the ATTACH to carry this sequence number.
      However, in certain error conditions, it is possible for the
      sending side to increment the sequence number and the receiver may
      not increment it.  When the sender sends a subsequent ATTACH, the
      receiver will detect a missing sequence.  This is allowed.
      However the sequence number received must always be larger than
      the previous one, even if some are missing.

      The maximum number of consecutive missing sequence numbers allowed
      is 16.  If this is exceeded, the session is unbound with a
      protocol violation.

      Note: The sequence number must be incremented for every ATTACH
      sent.  However, the sequence number field is only required to be
      included in the FMH5 if a password substitute is sent (byte 4, bit
      3 on).

   6. RDrSEQ = RDr + PWSEQs  /* RDr is server seed. */

      The current value of PWSEQs is added to RDr, the random value
      received from the partner LU on this session, yielding RDrSEQ,
      essentially a predictably modified value of the random value
      received from the partner LU at BIND time.




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


   7. PW_SUB = DES_CBC_mode(PW_TOKEN,        /* key      */
                            (RDrSEQ,         /* 8 bytes  */
                             RDs,            /* 8 bytes  */
                             ID xor RDrSEQ,  /* 16 bytes */
                             PWSEQs,         /* 8 bytes  */
                             )               /* data     */
                            )

       The PW_TOKEN is used as a key to the DES function to generate
       a 8 bytes value for the following string of inputs.  The DES
       CBC mode Initialization Vector (IV) used is 8 bytes of '00'X.

         RDrSEQ: the random data value received from the partner LU
                 plus the sequence number.

         RDs:    the random data value sent to the partner LU on BIND
                 for this session.

         A 16 byte value created by:

                 - padding the user identifier with '40'X to a
                   length of 16 bytes.

                 - Exclusive OR the two 8 byte halves of the padded
                   user identifier with the RDrSEQ value.

                 Note: User ID must first be converted to EBCDIC
                 upper case.

         PWSEQs: the sequence number.

      This is similar to the process used on LU-LU verification as
      described in the Enhanced LU-LU Bind Security.  The resulting
      enciphered random data is the 'password substitute'.

5.2 Handling passwords of length 9 and 10

   1. Generate PW_TOKENa by using characters 1 to 8 of the password and
      steps 1-4 from the previous section.

   2. Generate PW_TOKENb by using characters 9 and 10 and steps 1-4 from
      the previous section.  In this case Padded_PW from step 1 will be
      characters 9 and 10 padded to the right with '40'X, for a total
      length of 8.

   3. PW_TOKEN = PW_TOKENa xor PW_TOKENb





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


   4. Now compute PW_SUB by performing steps 5-7 from the previous
      section.

5.3 Example Password Substitute Calculation

   ID:           USER123
   Password:     ABCDEFG
   Server seed:  '7D4C2319F28004B2'X
   Client seed:  '08BEF662D851F4B1'X
   PWSEQs:       1     (PWSEQs is a sequence number needed in the
                        7-step encryption, and it is always one)

   Encrypted Password should be : '5A58BD50E4DD9B5F'X

6. Device Name Collision Processing

   Device name collision occurs when a Telnet client sends the Telnet
   server a virtual device name that it wants to use, but that device is
   already in use on the server.  When this occurs, the Telnet server
   sends a request to the client asking it to try another device name.
   The environment option negotiation uses the USERVAR name of DEVNAME
   to communicate the virtual device name.  The following shows how the
   Telnet server will request the Telnet client to send a different
   DEVNAME when device name collision occurs.

   AS/400 Telnet server             Enhanced Telnet client
   --------------------------       -------------------------
   IAC SB NEW-ENVIRON SEND
   VAR USERVAR IAC SE         -->

   Server requests all environment variables be sent.

                                    IAC SB NEW-ENVIRON IS USERVAR
                                    "DEVNAME" VALUE "MYDEVICE1"
                                    USERVAR "xxxxx" VALUE "xxx"
                                    ...
                              <--   IAC SE

   Client sends all environment variables, including DEVNAME.  Server
   tries to select device MYDEVICE1.  If the device is already in use,
   server requests DEVNAME be sent again.

   IAC SB NEW-ENVIRON SEND
   USERVAR "DEVNAME" IAC SE   -->







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


   Server sends a request for a single environment variable: DEVNAME

                                    IAC SB NEW-ENVIRON IS USERVAR
                              <--   "DEVNAME" VALUE "MYDEVICE2" IAC SE

   Client sends one environment variable, calculating a new value of
   MYDEVICE2.  If MYDEVICE2 is different from the last request, then
   server tries to select device MYDEVICE2, else server disconnects
   client.  If MYDEVICE2 is also in use, server will send DEVNAME
   request again, and keep doing so until it receives a device that is
   not in use, or the same device name twice in row.

7. Enhanced Printer 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
   select a previously created virtual device or auto-create a new
   virtual device with requested attributes.

   This makes the enhancements available to any Telnet client that
   chonoses to support the new negotiations.

   The USERVAR's defined to accomplish this are:

   USERVAR       VALUE            EXAMPLE           DESCRIPTION
   ------------- ---------------- ----------------  -------------------
   DEVNAME       us-ascii char(x) PRINTER1          Printer device name
   IBMIGCFEAT    us-ascii char(6) 2424J0            IGC feature (DBCS)
   IBMMSGQNAME   us-ascii char(x) QSYSOPR           *MSGQ name
   IBMMSGQLIB    us-ascii char(x) QSYS              *MSGQ library
   IBMFONT       us-ascii char(x) 12                Font
   IBMFORMFEED   us-ascii char(1) C | U | A         Formfeed
   IBMTRANSFORM  us-ascii char(1) 1 | 0             Transform
   IBMMFRTYPMDL  us-ascii char(x) *IBM42023         Mfg. type and model
   IBMPPRSRC1    binary(1)        1-byte hex field  Paper source 1
   IBMPPRSRC2    binary(1)        1-byte hex field  Paper source 2
   IBMENVELOPE   binary(1)        1-byte hex field  Envelope hopper
   IBMASCII899   us-ascii char(1) 1 | 0             ASCII 899 support
   IBMWSCSTNAME  us-ascii char(x) *NONE             WSCST name
   IBMWSCSTLIB   us-ascii char(x) *LIBL             WSCST library

   x - up to a maximum of 10 characters

   The "IBM" prefix on the USERVAR's denotes AS/400 specific attributes.

   The DEVNAME USERVAR is used both for displays and printers.  The
   IBMFONT and IBMASCII899 are used only for SBCS environments.



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


   For a description of most of these parameters (drop the "IBM" from
   the USERVAR) and their permissible values, refer to Chapter 8 in the
   Communications Configuration Reference [5].

   The IBMIGCFEAT supports the following variable DBCS language
   identifiers in position 5 (positions 1-4 must be '2424', position 6
   must be '0'):

        'J' = Japanese              'K' = Korean
        'C' = Traditional Chinese   'S' = Simplified Chinese

   The IBMTRANSFORM and IBMASCII899 values correspond to:

        '1' = Yes  '2' = No

   The IBMFORMFEED values correspond to:

        'C' = Continuous  'U' = Cut  'A' = Autocut