


Network Working Group                    Internet Engineering Task Force
Internet-Draft                                      Telnet Working Group
                                                       D. Borman, Editor
                                                     Cray Research, Inc.
                                                               July 1990


                      Telnet Authentication Option

Status of this Memo

   This draft document will be submitted to the RFC editor as a protocol
   specification.  Distribution of this memo is unlimited.  Please send
   comments to the telnet-ietf@cray.com mailing list.

1.  Command Names and Codes

   AUTHENTICATION TBA
       IS               0
       SEND             1
       REPLY            2

       Authentication Types
       NONE             0
       PRIVATE          1
       LOGIN            2
       KERBEROS         3

       Modifiers
       AUTH_WHO_CLIENT      0
       AUTH_WHO_SERVER      1
       AUTH_WHO_MASK        1

       AUTH_HOW_ONE_WAY     0
       AUTH_HOW_MUTUAL      2
       AUTH_HOW_MASK        2

2.  Command Meanings

   This document makes reference to a "server" and a "client".  For the
   purposes of this document, the "server" is the side of the connection
   that did the passive TCP open, and the "client" is the side of the
   connection that did the active open.

   IAC WILL AUTHENTICATION
   IAC DO AUTHENTICATION




Telnet Working Group                                            [Page 1]

Internet-Draft        Telnet Authentication Option             July 1990


      The sender of either of these commands is willing to send and re-
      ceive authentication information.  Typically, the server will send
      the DO, and the client the WILL.

   IAC WONT AUTHENTICATION

   IAC DONT AUTHENTICATION

      The sender of both of these commands refuses to send or receive
      authentication information.

   IAC SB AUTHENTICATION SEND authentication-type-list IAC SE

      The sender of this command (the server) requests that the remote
      side send authentication information for one of the authentication
      types listed in "authentication-type-list".  The "authentication-
      type-list" is an ordered list of "authentication-type" pairs.

   IAC SB AUTHENTICATION IS authentication-type-pair ... IAC SE

      The sender of this command (the client) is sending the authentica-
      tion information for authentication type "authentication-type-
      pair".

   IAC SB AUTHENTICATION REPLY authentication-type-pair ... IAC SE

      The sender of this command (the server) is sending a reply to the
      the authentication information received in a previous IS command.


   The "authentication-type-pair" has two values, the first is the au-
   thentication type, and the second is a modifier to the type.  There
   are currently two one bit fields defined in the modifer, the
   AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit, so there are four possi-
   ble combinations:

      AUTH_WHO_SERVER
      AUTH_HOW_ONE_WAY
         The server is authenticating the client.

      AUTH_WHO_CLIENT
      AUTH_HOW_ONE_WAY
         The client is authenticating the server.

      AUTH_WHO_SERVER
      AUTH_HOW_MUTUAL
         The client and server are authenticating each other, and the
         client will begin the negotiation.

      AUTH_WHO_CLIENT



Telnet Working Group                                            [Page 2]

Internet-Draft        Telnet Authentication Option             July 1990


      AUTH_HOW_MUTUAL
         The client and server are authenticating each other, and the
         server will begin the negotiation.

3.  Default Specification

   The default specification for this option is

      WONT AUTHENTICATION
      DONT AUTHENTICATION

   meaning there will not be any exchange of authentication information.

4.  Motivation

   One of the deficiences of the Telnet protocol is that in order to log
   into remote systems, users have to type their passwords, which are
   passed in clear text through the network.  If the connections goes
   through untrusted networks, there is the possibility that passwords
   will be compromised by someone watching the packets as they go by.

   The purpose of the AUTHENTICATION option is to provide a framework
   for the passing of authentication information through the TELNET ses-
   sion.  This means that: 1) the users password will not be sent in
   clear text across the network, and 2) if the front end telnet process
   has the appropriate authentication information, it can automatically
   send the information, and the user will not have to type any pass-
   word.

   It is intended that the AUTHENTICATION option be general enough that
   it can be used to pass information for any authentication system.

5.  Implementation Rules

   WILL and DO are used only at the beginning of the connection to ob-
   tain and grant permission for future negotiations.

   Typically, the server will send the "DO", and the client will send
   the "WILL".  Once the two hosts have exchanged a DO and a WILL, the
   server is free to request authentication information.  In the re-
   quest, a list of supported authentication types is sent.  Only the
   server may send requests ("IAC SB AUTHENTICATION SEND
   authentication-type-list IAC SE").  Only the client may transmit au-
   thentication information via the "IAC SB AUTHENTICATION IS
   authentication-type ... IAC SE" command.  Only the server may send
   replys ("IAC SB AUTHENTICATION REPLY authentication-type ... IAC
   SE").  As many IS and REPLY suboptions may be exchanged as are needed
   for the particular authentication scheme chosen.

   The authentication type of PRIVATE is intended for non-standard au-



Telnet Working Group                                            [Page 3]

Internet-Draft        Telnet Authentication Option             July 1990


   thentication schemes.  The type PRIVATE should only be used when
   there are no other supported authentication schemes in the authenti-
   cation list.

   The authentication type of LOGIN is intended for the normal
   "Login:/Password:" prompting.

   If the client does not support any of the authentication types listed
   in the authentication-type-list, a type of NONE may be used to indi-
   cate this in the IS reply.  Note that in this case, the server may
   choose to close the connection.  If the server is going to allow an
   un-authenticated session, it should include NONE as the last authen-
   tication type in the SEND command.

   The order of the authentication types MUST be ordered to indicate a
   preference for different authentication types, the first type being
   the most preferred, and the last type the least preferred.

   The following is an example of use of the option, Host1 is the
   client, and Host2 is the server:

       _H_o_s_t_1                            _H_o_s_t_2
                                        IAC DO AUTHENTICATION
                                        IAC DO ENVIRON
       IAC WILL AUTHENTICATION IAC WILL
       ENVIRON
       [ Host2 is now free to request authentication information.  The
         ENVIRON option will be used to pass the user name.  ]
                                        IAC SB ENVIRON SEND VAR "USER"
                                        IAC SE
                                        IAC SB AUTHENTICATION SEND KER-
                                        BEROS
                                        AUTH_WHO_CLIENT|AUTH_HOW_MUTUAL
                                        KERBEROS
                                        AUTH_WHO_CLIENT|AUTH_HOW_ONE_WAY
                                        LOGIN
                                        AUTH_WHO_CLIENT|AUTH_HOW_ONE_WAY
                                        IAC SE
       [ Host2 has requested two-way Kerberos authentication, is willing
         to just do one way Kerberos authentication, and will settle for
         normal login/password authentication if Kerberos is not sup-
         ported.  ]
       IAC SB ENVIRON IS VAR "USER"
       VALUE "joe" IAC SE
       IAC SB AUTHENTICATION IS KER-
       BEROS
       AUTH_WHO_CLIENT|AUTH_HOW_ONE_WAY
       "ticket" IAC SE
       [ The client responds with the name of the user in the ENVIRON
         option, and the Kerberos authentication information in the AU-



Telnet Working Group                                            [Page 4]

Internet-Draft        Telnet Authentication Option             July 1990


         THENTICATION option.  ]

   It is expected that any implementation that supports the Telnet AU-
   THENTICATION option will support all of this specification.

6.  References


   [1] Reynolds, Joyce, and Postel, Jon, "Assigned Numbers", RFC 993,
       ISI, November 1986

Author's Address

   David A. Borman, Editor
   Cray Research, Inc.
   655F Lone Oak Drive
   Eagan, MN 55123

   Phone: (612) 452-6650

   Mailing List: telnet-ietf@CRAY.COM
   EMail: dab@CRAY.COM































Telnet Working Group                                            [Page 5]

