RFC 1411

Telnet Authentication: Kerberos Version 4

📅 published January 1993, from ietf

RFC 1411: Telnet Authentication: Kerberos Version 4 🎀

Okay bestie, here's the lowdown on this one 💖

  • Network Working Group 🌐
  • Request for Comments: 1411
  • Editor: D. Borman, Editor, at Cray Research, Inc. 💅
  • Date: January 1993 📅
  • Category: Experimental Protocol 🧪 (see the Status section below)
  • Obsoletes / Updates: the header doesn't list any RFCs that this one obsoletes or updates ✨

Status of this Memo 🌸

So this memo defines an Experimental Protocol for the Internet community 🧪. They're asking for discussion and suggestions for improvement, so feel free to share your thoughts 🫶. If you want to know where this protocol stands in standardization, check the current edition of the "IAB Official Protocol Standards" 📚. Distribution of this memo is unlimited, so spread the love 💌

1. Command Names and Codes ✨

Here are the numbers and names you'll be seeing everywhere, so get comfy with them 👑

Authentication Types

   KERBEROS_V4  1

Suboption Commands

   AUTH         0
   REJECT       1
   ACCEPT       2
   CHALLENGE    3
   RESPONSE     4

2. Command Meanings 💬

Okay, this is the part where the magic happens 🔮 Every command below gets wrapped in IAC SB and IAC SE, so it's basically a little envelope with a message inside 💌

Here's the first one, which is how the Kerberos ticket gets sent over to the remote side:

IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <kerberos
ticket and authenticator> IAC SE

This is used to pass the Kerberos ticket to the remote side of the connection 📨 The first octet of the <authentication-type-pair> value is KERBEROS_V4, which tells everyone you're using Kerberos version 4 🔐

Next up is the success message:

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

This one means the authentication worked and it's giving main character energy ✅

And here's the not-so-great one:

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

This means the authentication didn't work 💀 If there's any leftover data in the sub-option, it's an ASCII text message explaining why it got rejected 🙈

Now for the mutual authentication duo, which is honestly iconic 👑

IAC SB AUTHENTICATION IS <authentication-type-pair> CHALLENGE
<encrypted challenge> IAC SE
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<encrypted response> IAC SE

These two commands are used to do mutual authentication 🤝 They only get used when the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair. After an AUTH gets sent and an ACCEPT comes back, a CHALLENGE is sent. The challenge is a random 8 byte number, with the most significant byte first and the least significant byte last 🎲 When the CHALLENGE command goes out, the "encrypted challenge" is that 8-byte challenge encrypted with the session key 🔑 When a CHALLENGE comes in, the contents get decrypted to recover the original 8-byte challenge. That value is then incremented by one, re-encrypted with the session key, and sent back as the "encrypted response" in the RESPONSE command 🔁 The receiver of the RESPONSE decrypts the "encrypted response" and checks that the result is the original 8-byte challenge plus one ✔️

One more fun fact 🍓 The "encrypted challenge" sent or received in the CHALLENGE command is also encrypted with the session key on both sides of the session. That produces a random 8-byte key, which is used as the default key for the ENCRYPTION option 🗝️

3. Implementation Rules 📜

If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_CLIENT_TO_SERVER, then the client sends the initial AUTH command, and the server responds with either ACCEPT or REJECT. Also, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL and the server responds with ACCEPT, then the client sends a CHALLENGE and the server sends a RESPONSE 🤝

If the second octet of the authentication-type-pair has the AUTH_WHO bit set to AUTH_SERVER_TO_CLIENT, then the server sends the initial AUTH command, and the client responds with either ACCEPT or REJECT. Also, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL and the client responds with ACCEPT, then the server sends a CHALLENGE and the client sends a RESPONSE 🔄

The authenticator (Kerberos Principal) used is of the form "rcmd.host@realm" 🪪

4. Examples 🧚

Okay, let's make this real. Say joe wants to log in as pete on the machine foo 🖥️ If pete has set things up on foo so joe can get into his account, the client sends this:

IAC SB AUTHENTICATION NAME "pete" IAC SE IAC SB AUTHENTICATION IS KERBEROS_V4 AUTH <joe's kerberos ticket> IAC SE

The server then authenticates the user as "joe" based on the ticket information. Since pete is letting joe use his account, the server sends back ACCEPT ✅ If mutual authentication is being used, the client sends a CHALLENGE and checks the RESPONSE that the server sends back 👀

Here's the whole conversation laid out, step by step:

    Client                           Server
                                     IAC DO AUTHENTICATION
    IAC WILL AUTHENTICATION
    [ The server is now free to request authentication information.
      ]
                                     IAC SB AUTHENTICATION SEND
                                     KERBEROS_V4 CLIENT|MUTUAL
                                     KERBEROS_V4 CLIENT|ONE_WAY IAC
                                     SE
    [ The server has requested mutual Version 4 Kerberos
      authentication.  If mutual authentication is not supported,
      then the server is willing to do one-way authentication.

      The client will now respond with the name of the user that it
      wants to log in as, and the Kerberos ticket.  ]
    IAC SB AUTHENTICATION NAME
    "pete" IAC SE
    IAC SB AUTHENTICATION IS
    KERBEROS_V4 CLIENT|MUTUAL AUTH
    <kerberos ticket information>
    IAC SE
    [ The server responds with an ACCEPT command to state that the
      authentication was successful.  ]
                                     IAC SB AUTHENTICATION REPLY
                                     KERBEROS_V4 CLIENT|MUTUAL ACCEPT
                                     IAC SE
    [ Next, the client sends across a CHALLENGE to verify that it is
      really talking to the right server.  ]
    IAC SB AUTHENTICATION IS
    KERBEROS_V4 CLIENT|MUTUAL
    CHALLENGE xx xx xx xx xx xx xx
    xx IAC SE
    [ Lastly, the server sends across a RESPONSE to prove that it
      really is the right server.
                                     IAC SB AUTHENTICATION REPLY
                                     KERBEROS_V4 CLIENT|MUTUAL
                                     RESPONSE yy yy yy yy yy yy yy yy
                                     IAC SE

Security Considerations 🚨

Okay bestie, this part is serious 😭 Negotiating a common authentication mechanism between client and server is a feature of the authentication option that you should use with caution. When the negotiation happens, 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 an authentication system that is either weak or already compromised by the intruder 💀

Author's Address 💌

Here's how to reach the editor 🫶

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

Phone: (612) 452-6650
EMail: dab@CRAY.COM

Mailing List: telnet-ietf@CRAY.COM

Chair's Address 🎀

The working group can be reached through the 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 thing, bestie! 🌈💖

📦 where this page comes from