RFC 927 PROPOSED STANDARD TELNET · AUTHENTICATION

TACACS Telnet option: TACACS user identification Telnet option

A Telnet option that lets a terminal access controller pass along a user's proven identity so the target host can skip a second login.

On rfc-editor.org ↗
PUBLISHED
December 1984
AUTHORS
B.A. Anderson
STREAM
Legacy
OPTION NAME
TUID
OPTION CODE
26
UUID SIZE
32 bit binary number
DOI
10.17487/RFC0927

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                  Brian A. Anderson
Request for Comments: 927                                            BBN
                                                           December 1984

                TACACS User Identification Telnet Option


Status of this Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Introduction

   The following is the description of a TELNET option designed to
   facilitate double login avoidance.  It is intended primarily for TAC
   connections to target hosts on behalf of TAC users, but it can be
   used between any two consenting hosts.  For example, all hosts at one
   site (e.g., BBN) can use this option to avoid double login when
   TELNETing to one another.

1. Command name and code

   TUID     26

2. Command Meanings

   IAC WILL TUID

      The sender (the TELNET user) proposes to authenticate the user and
      send the identifing UUID; or, the sender (the TELNET user) agrees
      to authenticate the user on whose behalf the connection is
      initiated.

   IAC WON'T TUID

      The sender (the TELNET user) refuses to authenticate the user on
      whose behalf the connection is initiated.

   IAC DO TUID

      The sender (the TELNET server) proposes that the recipient (the
      TELNET user) authenticate the user and send the identifing UUID;
      or, the sender (the TELNET server) agrees to accept the
      recipient's (the TELNET user's) authentication of the user
      identified by his UUID.

TUID Telnet Option


   IAC DON'T TUID

      The sender (the TELNET server) refuses to accept the recipient's
      (the TELNET user) authentication of the user.

   IAC SB TUID <uuid> IAC SE

      The sender (the TELNET user) sends the UUID <uuid> of the user on
      whose behalf the connection is established to the host to which he
      is connected.  The <uuid> is a 32 bit binary number.

3. Default

   WON'T TUID

      A TELNET user host (the initiator of a TELNET connection) not
      implementing or using the TUID option will reply WON'T TUID to a
      DO TUID.

   DON'T TUID

      A TELNET server host (the recipient of a TELNET connection) not
      implementing or using the TUID option reply DON'T TUID to a WILL
      TUID.

4. Motivation for the Option

   Under TACACS (the TAC Access Control System) a user must be
   authenticated (give a correct name/password pair) to a TAC before he
   can connect to a host via the TAC.  To avoid a second authentication
   by the target host, the TAC can pass along the user's proven identity
   (his UUID) to the that host.  Hosts may accept the TAC's
   authentication of the user or not, at their option.

   The same option can be used between any pair of cooperating hosts for
   the purpose of double login avoidance.

5. Description for the Option

   At the time that a host establishes a TELNET connection for a user to
   another host, if the latter supports the TUID option and wants to
   receive the user's UUID, it sends an IAC DO TUID to the the user's
   host.  If the user's host supports the TUID option and wants to
   authenticate the user by sending the user's UUID, it responds IAC
   WILL TUID; otherwise it responds with IAC WON'T TUID.  If both the
   user and server TELNETs agree, the user TELNET will then send the
   UUID to the server TELNET by sub-negotiation.

TUID Telnet Option


6. Examples

   There are two possible negotiations that result in the double login
   avoidance authentication of a user.  Both the server and the user
   TELNET support the TUID option.

      S = Server, U = User

      Case 1:

         S-> IAC DO TUID
         U-> IAC WILL TUID
         U-> IAC SB TUID <32-bit UUID> IAC SE

      Case 2:

         U-> IAC WILL TUID
         S-> IAC DO TUID
         U-> IAC SB TUID <32-bit UUID> IAC SE

   There are also two possible negoitiations that do not result in the
   authentication of a user.  In the first example the server supports
   TUID and the user TELNET doesn't.  In the second example the user
   TELNET supports TUID but the server TELNET doesn't.

      S = Server, U = User

      Case 3:

         S-> IAC DO TUID
         U-> IAC WONT TUID

      Case 4:

         U-> IAC WILL TUID
         S-> IAC DONT TUID

   The TUID is transmitted with the subnegotiation command.  For
   example, if the UUID had the value 1 the following string of octets
   would be transmitted:

      IAC SB TUID 0 0 0 1 IAC SE

   If the UUID had the value 255 the following string of octets would be
   transmitted:

      IAC SB TUID 0 0 0 IAC IAC IAC SE

TUID Telnet Option


   If the UUID had the value of all ones the following string of octets
   would be transmitted:

      IAC SB TUID IAC IAC IAC IAC IAC IAC IAC IAC IAC SE

AI ELI5

On this page
PROBLEMUnder TACACS a user must authenticate to a TAC before connecting to a host through it, and the target host would then ask for a login again.
MECHANISMThe TUID Telnet option, option code 26, lets the user's side send a 32-bit UUID for the user in a subnegotiation, after both sides agree with WILL and DO.
THE CATCHHosts may accept the TAC's authentication or not, at their option. The RFC is a proposed protocol that asks for discussion.

§1Avoiding a Double Login

Under TACACS (the TAC Access Control System) a user must give a correct name and password pair to a TAC before he can connect to a host via the TAC. To avoid a second authentication by the target host, the TAC can pass along the user's proven identity, his UUID, to that host. Hosts may accept the TAC's authentication of the user or not, at their option.

The option is intended mainly for TAC connections made for TAC users, but it can be used between any two consenting hosts, for example all hosts at one site.

The first door already checked your ID, so it tells the second door your ID number and you can walk right in.

§2The TUID Option Commands

The option is named TUID and has code 26. It uses the usual Telnet commands:

  • IAC WILL TUID: the user side proposes to authenticate the user and send the UUID, or agrees to do so.
  • IAC WON'T TUID: the user side refuses.
  • IAC DO TUID: the server proposes that the user side authenticate and send the UUID, or agrees to accept it.
  • IAC DON'T TUID: the server refuses to accept the authentication.
  • IAC SB TUID <uuid> IAC SE: the user side sends the UUID, a 32 bit binary number.

By default a host that does not implement the option answers WON'T TUID to a DO, or DON'T TUID to a WILL.

The two computers ask each other yes or no questions first. Only if both say yes does the ID number get sent.

§3Negotiation Cases and Encoding

Either side can start. In case 1 the server sends DO and the user replies WILL, and in case 2 the user sends WILL first and the server replies DO. In both, the user then sends the UUID by subnegotiation. If one side lacks the option, the answer is WON'T or DON'T and no authentication happens.

The UUID is sent as four octets. A value of 1 goes out as IAC SB TUID 0 0 0 1 IAC SE. A byte of value 255 has to be doubled, so the value 255 goes out as IAC SB TUID 0 0 0 IAC IAC IAC SE, and all ones goes out as eight IAC octets between TUID and the final IAC SE.

Both must agree before the ID is sent, and some special number values are written in a doubled way so they are not mistaken for commands.

CASE 1 FROM RFC 927: SERVER ASKS FIRST
Server TELNETUser TELNET
  1. IAC DO TUIDServer asks the user side to authenticate.
  2. IAC WILL TUIDUser side agrees.
  3. IAC SB TUID <32-bit UUID> IAC SEThe UUID is sent by subnegotiation.