RFC 1412

Telnet Authentication: SPX 🎀

okay bestie, here's the vibe check on this one 🧚 RFC 1412 from the Network Working Group 💖, written by K. Alagappan at Digital Equipment Corporation, dated January 1993. It's an Experimental Protocol 🧪, and the title block doesn't list anything it obsoletes or updates.

Status of This Memo ✨

so basically this memo defines an Experimental Protocol for the Internet community 🌈. People are literally invited to talk about it and suggest improvements 🫶. For the official standardization state and status of this protocol, go check the current edition of the "IAB Official Protocol Standards" 📚. Distribution of this memo is unlimited 💅.

1. Command Names and Codes 💅

these are the names and numbers you'll see floating around 👀

Authentication Types

   SPX          3

Suboption Commands

   AUTH         0
   REJECT       1
   ACCEPT       2

2. Command Meanings 🦋

The AUTH command 🔑

this is how the SPX authentication token gets sent over to the remote side of the connection ✨

IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH
<SPX authentication token> IAC SE

the doc that explains the token syntax is still coming, so hold tight 💌. The first octet of the <authentication-type-pair> value is SPX 🎀. The second octet is a modifier to the SPX authentication type, which is giving main character energy 👑.

The ACCEPT command 🫧

this one means the authentication worked, periodt 🙌

IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
<mutual response> IAC SE

after an SPX authentication exchange, both sides have securely established a random 8-byte key 🔐. That key is the default key for the ENCRYPTION option, so it's iconic and it's important 🍓. If the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair, the sender includes the mutual response bytes 🤝. The receiver of the ACCEPT command compares the "mutual response" with its expected mutual response 🔍.

the doc for mutual response syntax is also still coming 🙈. If the AUTH_HOW_ONE_WAY bit is set in the second octet of the authentication-type-pair, the sender includes zero bytes of mutual response 🌸.

The REJECT command 💀

this one means the authentication did not work 😭. If there's any more data in the sub-option, it's an ASCII text message explaining the reason for the rejection 📝.

IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
<optional reason for rejection> IAC SE

3. Implementation Rules 📜

ok this part is the lowkey strict stuff 🫣. Every command after the first AUTHENTICATION IS must carry the same set of modifiers (e.g., CLIENT|MUTUAL) for subsequent AUTHENTICATION IS and AUTHENTICATION REPLY commands 🔗.

If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_WHO_CLIENT, then the client sends the initial AUTH command, and the server responds with either ACCEPT or REJECT 📤.

If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_WHO_SERVER, then the server sends the initial AUTH command, and the client responds with either ACCEPT or REJECT 📥.

4. Examples 🧚‍♀️

okay the example is so cute, it's basically a story 📖. User "joe" wants to log in as user "pete" on machine "foo" 💁. If "pete" has set things up on "foo" to let "joe" access his account, then the client sends this:

IAC SB AUTHENTICATION NAME "pete" IAC SE
IAC SB AUTHENTICATION IS SPX AUTH <joe's spx authentication
token> IAC SE

The server then authenticates the user as "joe" from the token information, and it sends back either ACCEPT or REJECT 🎟️. If mutual authentication is being used, the server includes a mutual response in the ACCEPT message 🤝.

⚠️ bestie, the authorization check is separate! It happens after the authentication exchange is complete. So it's possible for the client to receive an ACCEPT (based on the authentication token) but for joe to still be denied access to log in to pete's account 😭💅.

here's the whole sequence, in all its glory 🎬

    Client                           Server
                                     IAC DO AUTHENTICATION
    IAC WILL AUTHENTICATION

    [ The server is now free to request authentication information.
      ]

                                     IAC SB AUTHENTICATION SEND SPX
                                     CLIENT|MUTUAL SPX CLIENT|ONE_WAY
                                     IAC SE

    [ The server has requested mutual SPX authentication.  If mutual
      authentication is not supported, then the server is willing to
      do one-way SPX authentication.  ]

    [ The client will now respond with the name of the user that it
      wants to log in as, and the SPX authentication token.  ]

    IAC SB AUTHENTICATION NAME
    "pete" IAC SE
    IAC SB AUTHENTICATION IS SPX
    CLIENT|MUTUAL AUTH <spx
    authentication token
    information> IAC SE

    [ The server responds with an ACCEPT command to state that the
      authentication was successful.  ]

    [ If AUTH_HOW_MUTUAL, the server responds with the mutual
      response so the client can verify that it is really talking to
      the right server.  ]

    [ If AUTH_HOW_ONE_WAY, the server responds with a NULL mutual
      response, since the client is willing to trust the server
      already.  ]

                                     IAC SB AUTHENTICATION REPLY SPX
                                     CLIENT|MUTUAL ACCEPT <mutual
                                     response> IAC SE

Security Considerations 🔒

🚨 okay, this part is seriously important, so no skipping! 🚨

the ability to negotiate a common authentication mechanism between client and server is a feature of the authentication option that should be used with caution 😬. When the negotiation is performed, no authentication has happened yet 🫣. So each system has no way of knowing whether or not it's talking to the system it intends 👀. An intruder could try to negotiate the use of an authentication system that's either weak, or already compromised by the intruder 💀. That's a whole mood, so be careful out there 🛡️.

Author's Address 💌

the author is Kannan Alagappan at Digital Equipment Corporation:

Kannan Alagappan
Digital Equipment Corporation
550 King Street, LKG1-2/A19
Littleton, MA 01460

EMail: kannan@sejour.lkg.dec.com

Mailing List: telnet-ietf@CRAY.COM

the working group can be reached through its current chair 🧑‍💻:

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 RFC, bestie! 💖 Authentication is a big deal, so keep it cute and keep it careful 🦋✨