RFC 1409

Telnet Authentication Option

📅 published January 1993, from ietf

RFC 1409: Telnet Authentication Option 🎀

Okay bestie, this is RFC 1409, the Telnet Authentication Option. It's from the Network Working Group, dated January 1993, with D. Borman as editor at Cray Research, Inc. It's an Experimental Protocol 🧪, so the team is asking for discussion and suggestions. The title block doesn't list anything it obsoletes or updates.

Status of This Memo 📣

This memo defines an Experimental Protocol for the Internet community, and discussion and suggestions for improvement are requested. For the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards". Distribution of this memo is unlimited. 💌

1. Command Names and Codes ✨

Here are all the codes in one table. I'm keeping it exactly as-is in the code block so nothing gets lost 📋

   AUTHENTICATION  37
       IS               0
       SEND             1
       REPLY            2
       NAME             3

       Authentication Types
       NULL             0
       KERBEROS_V4      1
       KERBEROS_V5      2
       SPX              3
       RSA              6
       LOKI            10

       Modifiers
       AUTH_WHO_MASK        1
       AUTH_CLIENT_TO_SERVER    0
       AUTH_SERVER_TO_CLIENT    1
       AUTH_HOW_MASK        2
       AUTH_HOW_ONE_WAY         0
       AUTH_HOW_MUTUAL          2

2. Command Meanings 💬

This doc talks about a "server" and a "client" 🫶 For this doc, the "server" is the side of the connection that did the passive TCP open (the TCP LISTEN state), and the "client" is the side that did the active open.

Now for the commands, starting with the WILL and DO family:

IAC WILL AUTHENTICATION

The client side sends this one to say it's willing to send and receive authentication information. 💖

IAC DO AUTHENTICATION

The server side sends this one to say it's willing to send and receive authentication information. 🌸

IAC WONT AUTHENTICATION

The client side sends this to say it refuses to send or receive authentication information. The server side sends this command if it receives a DO AUTHENTICATION command. 🙅‍♀️

IAC DONT AUTHENTICATION

The server side sends this to say it refuses to send or receive authentication information. The client side sends this command if it receives a WILL AUTHENTICATION command. 🙅‍♀️

Next up is the SEND request:

IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE

The sender here is the server. It's asking the remote side to send authentication information for one of the authentication types in the "authentication-type-pair-list". That list is an ordered list of "authentication-type" pairs. Only the server side (the one that sent DO AUTHENTICATION) is allowed to send this. 📨

IAC SB AUTHENTICATION IS authentication-type-pair <auth data> IAC SE

The sender here is the client, and it's sending the authentication information for the "authentication-type-pair". Only the client side (WILL AUTHENTICATION) is allowed to send this. 🔑

IAC SB AUTHENTICATION REPLY authentication-type-pair <auth data> IAC
SE

The sender here is the server, and it's replying to the authentication information it got in a previous IS command. Only the server side (DO AUTHENTICATION) is allowed to send this. 💬

IAC SB AUTHENTICATION NAME remote-user IAC SE

This one is optional 🤍 It's sent to specify the account name on the remote host that the user wants to be authorized to use. Note that authentication may succeed, and the authorization to use a particular account may still fail. Some authentication mechanisms may ignore this command. 🙈

The "authentication-type-pair" is two octets. The first one is the authentication type (as listed in Section 1; additions to that list must be registered with the Internet Assigned Numbers Authority (IANA)). The second one is a modifier to the type. Right now there are two one-bit fields defined in the modifier, the AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit, so there are four possible combinations 🧩

AUTH_CLIENT_TO_SERVER
AUTH_HOW_ONE_WAY

The client sends authentication information about the local user to the server. If the negotiation is successful, the server has authenticated the user on the client side of the connection. ✅

AUTH_SERVER_TO_CLIENT
AUTH_HOW_ONE_WAY

The server authenticates itself to the client. If the negotiation is successful, the client knows it's connected to the server it wants to be connected to. 🫶

AUTH_CLIENT_TO_SERVER
AUTH_HOW_MUTUAL

The client sends authentication information about the local user to the server, and then the server authenticates itself to the client. If the negotiation is successful, the server has authenticated the user on the client side of the connection, and the client knows it's connected to the server it wants to be connected to. 👑

AUTH_SERVER_TO_CLIENT
AUTH_HOW_MUTUAL

The server authenticates itself to the client, and then the client authenticates itself to the server. If the negotiation is successful, the client knows it's connected to the server it wants to be connected to, and the server knows the client is who it claims to be. 🥹

3. Default Specification 🧸

The default specification for this option is:

WONT AUTHENTICATION
DONT AUTHENTICATION

This means there won't be any exchange of authentication information. Quiet vibes only 🤫

4. Motivation 🌸

One of the deficiencies of the Telnet protocol is that, to log into remote systems, users have to type their passwords, and those passwords get passed in clear text through the network. If the connection goes through untrusted networks, there's a real possibility that someone watching the packets go by could compromise the passwords. 👀

That's where the AUTHENTICATION option comes in. Its purpose is to provide a framework for passing authentication information through the TELNET session. That means two things: 1) the user's password won't be sent across the network in clear text, and 2) if the front-end telnet process has the right authentication information, it can send that information automatically, so the user doesn't have to type any password. 🔐

The option is meant to be general enough to pass information for any authentication system. 🧚

5. Security Implications 🚨

Negotiating a common authentication mechanism between client and server is a feature of the authentication option, and it should be used with caution. 🫣

💀 Bestie, this part is serious. When the negotiation is performed, no authentication has happened yet. That means each system has no way of knowing whether or not it's talking to the system it intends to talk to. An intruder could try to negotiate the use of an authentication system that is either weak, or already compromised by the intruder.

6. Implementation Rules 📜

WILL and DO are only used at the beginning of the connection, to obtain and grant permission for future negotiations. 🤝

Authentication is only negotiated in one direction: the server must send the "DO", and the client must send the "WILL". This restriction comes from the nature of authentication, because there are three possible cases: the server authenticates the client, the client authenticates the server, or the server and client authenticate each other. By only negotiating the option in one direction, and then figuring out which of the three cases is in use via the suboption, the potential ambiguity is removed. 🧠 If the server receives a "DO", it must respond with a "WONT". If the client receives a "WILL", it must respond with a "DONT".

Once the two hosts have exchanged a DO and a WILL, the server is free to request authentication information. In that request, a list of supported authentication types is sent. Only the server may send requests (IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE). Only the client may transmit authentication information with the IAC SB AUTHENTICATION IS authentication-type ... IAC SE command. Only the server may send replies (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. 🔁

If the client doesn't support any of the authentication types listed in the authentication-type-pair-list, a type of NULL should be used to indicate this in the IS reply. Note that in this case, the server may choose to close the connection. 🚪

The order of the authentication types MUST be set up to show preference: the first type is the most preferred, and the last type is the least preferred. 🥇

✨ That's part 1 of 2! The example of use and everything after it is coming up in part 2 💖

Chair's Address 💖

okay so bestie, if you need to reach the working group, the move is to contact the current chair 💅 right now that's Steve Alexander, over at INTERACTIVE Systems Corporation. here's where to find him, all verbatim so you don't mess it up ✨

Steve Alexander
INTERACTIVE Systems Corporation
1901 North Naper Boulevard
Naperville, IL 60563-8895

Phone: (708) 505-9100 x256
EMail: stevea@isc.com

that's the whole address, no cap 🦋

📦 where this page comes from

ietf: rfc1409 1993-01
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms