RFC 2941
Telnet Authentication Option
RFC 2941: Telnet Authentication Option 🎀
Part 1 of 3 🦋
Okay bestie, let's get into this one. It's RFC 2941, titled Telnet Authentication Option. The editor is T. Ts'o from VA Linux Systems, and J. Altman from Columbia University is also on it. It's dated September 2000 and it's a Standards Track document. It obsoletes RFC 1416, and the abstract says it also updates that same spec 💅
Status of This Memo
This doc specifies an Internet standards track protocol for the Internet community and asks for discussion and suggestions for improvements 🌸 For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract
This document describes the authentication option to the telnet [1] protocol 🧚 It's a generic way to negotiate an authentication type and mode, and that includes whether encryption should be used and whether credentials should be forwarded. It summarizes the commands and types that are used right now, but it does NOT define a specific authentication type. Separate documents are going to be published to define each one 📚
This document updates the older telnet authentication option spec, RFC 1416 [2], so it can securely enable the telnet encryption option [3] 🔐
1. Command Names and Codes ✨
Here's the lineup of names and numbers 💖
AUTHENTICATION 37
Authentication Commands
IS 0
SEND 1
REPLY 2
NAME 3
Authentication Types
NULL 0
KERBEROS_V4 1
KERBEROS_V5 2
SPX* 3
MINK* 4
SRP 5
RSA*[also used by SRA*] 6
SSL* 7
[unassigned] 8
[unassigned] 9
LOKI* 10
SSA* 11
KEA_SJ 12
KEA_SJ_INTEG 13
DSS 14
NTLM* 15Anything with a (*) never got submitted to the IETF to be considered as an Internet standard 🙈
Following historical practice, future authentication type numbers and authentication modifiers will be assigned by IANA under a First Come First Served policy, as laid out in RFC 2434 [4] 🍓 The authentication type numbers come from an 8-bit number space (just like most values in the telnet spec), but nobody expects that space to run out or become in danger of running out. Still, if it ever becomes an issue, once over 50% of the number space is allocated, IANA shall refer allocation requests to either the IESG or a designated expert for approval. IANA is also instructed not to issue new suboption values without submission of documentation of their use 🫶
Modifiers, periodt 👑
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
ENCRYPT_MASK 20
ENCRYPT_OFF 0
ENCRYPT_USING_TELOPT 4
ENCRYPT_AFTER_EXCHANGE 16
ENCRYPT_RESERVED 20
INI_CRED_FWD_MASK 8
INI_CRED_FWD_OFF 0
INI_CRED_FWD_ON 82. Command Meanings 🌈
In this doc, there's a "server" and a "client". The "server" is the side of the connection that did the passive TCP open (TCP LISTEN state), and the "client" is the side that did the active open 🦋
IAC WILL AUTHENTICATION
The client side sends this to say it's willing to send and receive authentication information 💅
IAC DO AUTHENTICATION
The server side sends this 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 must send 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 must send this command if it receives a WILL AUTHENTICATION command 💀
IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE
The sender of this command (the server) asks the remote side to send authentication information for one of the authentication types listed in "authentication-type-pair-list". That list is an ordered list of "authentication-type" pairs. Only the server side (DO AUTHENTICATION) is allowed to send this 🎀
IAC SB AUTHENTICATION IS authentication-type-pair <auth data> IAC SE
The sender of this command (the client) is sending the authentication information for the authentication type "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 of this command (the server) is 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 is an optional command used to specify the account name on the remote host that the user wants to be authorized to use. Heads up: authentication can succeed while the authorization to use that particular account still fails 😭 Some authentication mechanisms may ignore this command 🫶
The "authentication-type-pair" is two octets. The first is the authentication type, and the second is a modifier to that type. The authentication type may or may not include built-in encryption. For example, when Kerberos 4 is negotiated, encryption MUST be negotiated with the telnet ENCRYPT option. But the SSL and KEA_SJ authentication types give you an encrypted channel as part of a successful telnet AUTH option negotiation 🔐
There are currently five one-bit fields defined in the modifier. The first two are processed as a pair: the AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit. There are four possible combinations of those two bits 🧠
AUTH_CLIENT_TO_SERVER with AUTH_HOW_ONE_WAY
The client sends authentication information about the local user to the server. If the negotiation works, the server will have authenticated the user on the client side of the connection 🙌
AUTH_SERVER_TO_CLIENT with AUTH_HOW_ONE_WAY
The server authenticates itself to the client. If the negotiation works, the client knows it's connected to the server it wanted to connect to 🌟
AUTH_CLIENT_TO_SERVER with 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 works, the server has authenticated the user on the client side, and the client knows it's connected to the server it wanted 💅
AUTH_SERVER_TO_CLIENT with AUTH_HOW_MUTUAL
The server authenticates itself to the client, and then the client authenticates itself to the server. If the negotiation works, the client knows it's connected to the server it wanted, and the server knows the client is who it claims to be 👑
The third and fifth bits in the modifier are the ENCRYPT_MASK bits. They decide if and how encryption gets enabled. Of the four possible combinations, only three are currently defined 🌸
ENCRYPT_OFF
Encryption won't be used for this session. TELOPT ENCRYPT SHOULD NOT be negotiated. This mode MUST be used with all AUTH types that don't provide a shared secret to be used as a session key 🙈
ENCRYPT_USING_TELOPT
Encryption gets negotiated through TELOPT ENCRYPT. Right after authentication completes, TELOPT ENCRYPT MUST be negotiated in both directions. This has to happen before credentials forwarding, before other telnet options are negotiated, and before any user data is transmitted. If TELOPT ENCRYPT fails to negotiate in either direction, that MUST result in immediate session termination 💀
ENCRYPT_AFTER_EXCHANGE
Encryption gets activated in both directions right after the shared secret is successfully exchanged, and that secret becomes the session key. The encryption algorithm to be used MUST be implied by the AUTH type 🔥
The fourth bit field in the modifier is the INI_CRED_FWD_MASK bit. It's set to either INI_CRED_FWD_ON or INI_CRED_FWD_OFF. The client sets it to advise the server to expect forwarded credentials from the client 🎀
INI_CRED_FWD_OFF
The client will not be forwarding credentials to the server. This mode must be used if the selected authentication method doesn't support credentials forwarding 🙅♀️
INI_CRED_FWD_ON
Once authentication, and maybe encryption, completes, the client immediately forwards its authentication credentials to the server ✨
The reason for this advisory bit is that the server might want to wait until the forwarded credentials have arrived before it starts any operating system specific login procedures that depend on them 🧚 Note that not every authentication mechanism supports credentials forwarding. It's a protocol error to set this bit if the underlying authentication mechanism doesn't support credentials forwarding 🚫
Credentials forwarding MUST NOT be performed if AUTH_CLIENT_TO_SERVER|AUTH_HOW_ONE_WAY was used, since the identity of the server cannot be assured 😤 Credentials SHOULD NOT be forwarded if the telnet connection isn't protected by some encryption or integrity protection service 🔒
Also, older implementations of the telnet authentication option won't understand the ENCRYPT_MASK and INI_CRED_FWD_MASK bits. So if an implementation wants to offer these bits and backwards compatibility is needed, it should offer authentication type pairs with those bits both set and not set 🍓
3. Default Specification 💤
The default specification for this option is:
WONT AUTHENTICATION DONT AUTHENTICATIONThis means there won't be any exchange of authentication information at all 🌙
(to be continued in Part 2 💖)
4. Motivation ✨
okay so the big problem with Telnet 💀 is that to log into a remote system, you have to type your password, and it zooms across the network in clear text. if your connection goes through untrusted networks, anyone watching the packets in transit could snag it. not it 🙅♀️
the AUTHENTICATION option is basically the glow-up fix 🦋 it gives you a framework for passing authentication info through the TELNET session, plus a way to turn on encryption of the data stream as a side effect of successful authentication, or later with the telnet ENCRYPT option. so here's what that gets us: 1) the users password never goes across the network in clear text, 2) if the front end telnet process already has the right authentication info, it can send it automatically, so the user never has to type a password at all 🫶 and 3) once authentication succeeds, the data stream can be encrypted, which protects it against active attacks. iconic, honestly 👑
it's also meant to be general enough to pass info for any authentication and encryption system. like, not just one flavour, the whole buffet 🍓
5. Security Implications 🔥
okay this section is giving serious "be careful bestie" energy 😭 negotiating a common authentication mechanism between client and server is a feature you should use with caution. when the negotiation happens, nobody has authenticated yet, so each system has no way of knowing whether it's actually talking to the system it intends. an intruder could try to negotiate an authentication system that's either weak, or already compromised by them 💀
if the authentication type requires encryption to be enabled as a separate optional negotiation (the ENCRYPT option), there's a window of vulnerability from the moment authentication completes, all the way up to the negotiation that turns encryption on. an active attacker could exploit that. "active attack" here just means the underlying TCP stream can be modified or taken over by the attacker. yikes 🙈 the fix: if the server only offers authentication type pairs that include ENCRYPT_USING_TELOPT set in the ENCRYPT_MASK field, that avoids the window entirely, because both parties agree that the telnet ENCRYPT option must be successfully negotiated right after telnet AUTH completes. main character energy ✨
other authentication types link turning on encryption to successful authentication as a side effect. that also protects against the active attacker 💖 and the ENCRYPT_AFTER_EXCHANGE bit lets those types negotiate encryption so it can be made optional.
another opening for active attacks shows up when encryption can be turned on and off without re-authentication. once encryption is disabled, an attacker can hijack the telnet stream and mess with attempts to restart it 😤 so, a client SHOULD NOT support the ability to turn off encryption 🛑 and once encryption is disabled, if an attempt to re-enable it fails, the client MUST terminate the telnet connection. no exceptions, periodt 💅
it's also important that, in both cases, the authentication type pair is integrity protected at the end of the authentication exchange. this must be specified for each authentication type so the result of the telnet authentication option negotiation is agreed to by both the client and the server 🫶 some authentication type suboptions may want to include all of the telnet authentication negotiation exchanges in the integrity checksum, so the entire exchange is fully protected ✨
and this one is non-negotiable: each side MUST verify the consistency of the auth-type-pairs in each message it receives. any variation in the auth-type-pair MUST be treated as a fatal protocol error 💀🔥
6. Implementation Rules 🧚
WILL and DO are only used at the very beginning of the connection, to obtain and grant permission for future negotiations. that's it, that's the tea ☕
authentication is only negotiated in one direction: the server must send the "DO", and the client must send the "WILL". why? because there are three possible cases: server authenticates client, client authenticates server, and server and client authenticate each other. by only negotiating in one direction and then figuring out which of the three cases is in play via the suboption, the potential ambiguity just disappears 🦋 so if the server receives a "DO", it must respond with a "WONT". if the client receives a "WILL", it must respond with a "DONT". clean 💜
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 gets sent. only the server may send requests (IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE). only the client may transmit authentication information via 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 the particular authentication scheme needs 🌈
if the client doesn't support any of the authentication types in the authentication-type-pair-list, a type of NULL should be used to say so in the IS reply. heads up though: if the client responds with a type of NULL, the server may choose to close the connection 🙈
when the server has concluded that authentication can't be negotiated with the client, it should send IAC DONT AUTH to the client 🫠
the order of the authentication types MUST indicate preference, with the first type being the most preferred and the last type the least preferred. ranking time 👑
as long as the server is WILL AUTH, it may request authentication information at any time. it does this by sending a new list of supported authentication types. asking again can be a way to verify the validity of the client's credentials after an extended period of time, or to negotiate a new session key for use during encryption 🔐
7. User Interface 🎀
normally protocol specs don't address user interfaces, but the user will probably want to configure authentication and encryption and know whether the negotiations succeeded. so some guidance is needed to give implementors a minimum level of user control 💖
the user MUST be able to specify whether authentication is to be used, and whether encryption is to be used if authentication succeeds. there SHOULD be at least four settings: REQUIRE, PROMPT, WARN and DISABLE 🌸
REQUIRE: if authentication fails, an appropriate error message must be displayed and the TELNET connection must be terminated. bestie, that's a hard stop 🛑
PROMPT: if authentication fails, an appropriate error message must be displayed and the user must be prompted for confirmation before the TELNET session continues. 🙋♀️
WARN: if authentication fails, an appropriate error message must be displayed before the TELNET session continues. heads up, but no hard stop ⚠️
DISABLE: authentication will not be attempted at all 🙅♀️
the encryption switch SHOULD have the same settings as the authentication switch, but its settings are only used when authentication succeeds. the default setting for both switches should be WARN ✨ both of these switches can be implemented as a single switch, though having them separate gives the user more control, and honestly control is everything 💅
8. Example ✨
okay bestie, here's how it actually plays out 💖 Three walkthroughs, client on the left, server on the right. Read them like a group chat and the handshake is super easy to follow 🦋
Example one is mutual Kerberos auth. The server asks for mutual, but it's willing to settle for one-way, and the client just rolls with it 💅
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 Kerberos authentication, but is
willing to do just one-way Kerberos 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 "joe"
IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4 CLIENT|MUTUAL AUTH 4
7 1 67 82 65 89 46 67 7 9 77 0
48 24 49 244 109 240 50 208 43
35 25 116 104 44 167 21 201 224
229 145 20 2 244 213 220 33 134
148 4 251 249 233 229 152 77 2
109 130 231 33 146 190 248 1 9
31 95 94 15 120 224 0 225 76 205
70 136 245 190 199 147 155 13
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 SEExample two is the same vibe, but now encryption gets negotiated through telnet ENCRYPT too 🔐 The big moment is the end, where both sides start the ENCRYPT option in each direction.
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|ENCRYPT_USING_TELOPT
KERBEROS_V4 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Kerberos authentication, but is
willing to do just one-way Kerberos authentication. In both
cases it is willing to encrypt the data stream. 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 "joe"
IAC SE
IAC SB AUTHENTICATION IS
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
AUTH 4 7 1 67 82 65 89 46 67 7 9
77 0 48 24 49 244 109 240 50 208
43 35 25 116 104 44 167 21 201
224 229 145 20 2 244 213 220 33
134 148 4 251 249 233 229 152 77
2 109 130 231 33 146 190 248 1 9
31 95 94 15 120 224 0 225 76 205
70 136 245 190 199 147 155 13
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
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|ENCRYPT_USING_TELOPT
CHALLENGE xx xx xx xx xx xx xx
xx IAC SE
[ The server sends across a RESPONSE to prove that it really is
the right server. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V4
CLIENT|MUTUAL|ENCRYPT_USING_TELOPT
RESPONSE yy yy yy yy yy yy yy yy
IAC SE
[ At this point, the client and server begin to negotiate the
telnet ENCRYPT option in each direction for a secure channel.
If the option fails in either direction for any reason the
connection must be immediately terminated. ]⚠️ if the ENCRYPT option fails in either direction for any reason, the connection must be immediately terminated. no exceptions, no debate 💀
Example three is integrated encryption with KEA and SKIPJACK, and it's giving full spy movie 🕵️♀️ Note how the encryption kicks in right after the exchange, not as a separate negotiation.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
IAC SE
[ The server has requested mutual KEA authentication with
SKIPJACK encryption. The client will now respond with the name
of the user that it wants to log in as and the KEA cert. ]
IAC SB AUTHENTICATION NAME "joe"
IAC SE IAC SB AUTHENTICATION IS
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'1' CertA||Ra IAC SE
[ The server responds with its KEA Cert. ]
IAC SB AUTHENTICATION REPLY
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'2'
CertB||Rb||IVb||Encrypt(NonceB)
IAC SE
[ Next, the client sends across a CHALLENGE to verify that it is
really talking to the right server. ]
IAC SB AUTHENTICATION IS KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'3' IVa||Encrypt( NonceB xor
0x0C18 || NonceA ) IAC SE
[ At this point, the client begins to encrypt the outgoing data
stream, and the server, after receiving this command, begins to
decrypt the incoming data stream. Lastly, the server sends
across a RESPONSE to prove that it really is the right server.
]
IAC SB AUTHENTICATION REPLY
KEA_SJ
CLIENT|MUTUAL|ENCRYPT_AFTER_EXCHANGE
'4' Encrypt( NonceA xor 0x0C18 )
IAC SE
[ At this point, the server begins to encrypt its outgoing data
stream, and the client, after receiving this command, begins to
decrypt its incoming data stream. ]Last thing: any implementation that supports the Telnet AUTHENTICATION option is expected to support all of this specification. So no picking and choosing, babe 🎀
9. Security Considerations 🚨
okay, this part is lowkey the most important part of the whole doc, so please pay attention 🥺
This memo describes a general framework for adding authentication and encryption to the telnet protocol. The actual authentication mechanism lives in the authentication suboption specifications, so the security of the authentication option depends entirely on the strengths and weaknesses of whichever suboption you pick 💜
Now the scary bit 😭 The negotiation of the authentication type pair is not protected. That means an attacker can push the result down to the weakest method both sides are willing to accept. For example, say both sides could handle a "strong" mechanism and a "40-bit" mechanism. An attacker could force the "40-bit" one, and nobody would notice until it's too late. So an implementation should only accept an authentication mechanism to be negotiated if it actually trusts that mechanism to be secure. No vibes-based trust, only real trust ✨
Also, the negotiation of the username in the IAC SB AUTHENTICATION NAME name IAC SE message is not protected either. Implementations should verify that value by a secure method before using this untrusted value. Basically, don't believe every name that shows up in the chat 🙈
11. Acknowledgements 🫶
so many people worked on this doc over the years, and that's a whole mood 🌸 Dave Borman was the document editor and wrote most of the original text, which is iconic behavior. Other folks who threw in ideas and suggestions include David Carrel, Jeff Schiller, and Richard Basch. Thank you, queens 👑
10. References 📚
- [1] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983.
- [2] Borman D., "Telnet Authentication Option", RFC 1416, February 1993.
- [3] Ts'o, T., "Telnet Data Encryption Option", RFC 2946, September 2000.
- [4] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
12. Authors' Addresses 💌
Here are the people behind it, plus the mailing list where the chaos happens 🧚
Theodore Ts'o, Editor
VA Linux Systems
43 Pleasant St.
Medford, MA 02155
Phone: (781) 391-3464
EMail: tytso@mit.edu
Jeffrey Altman
Columbia University
Watson Hall Room 716
612 West 115th Street
New York NY 10025
Phone: +1 (212) 854-1344
EMail: jaltman@columbia.edu
Mailing List: telnet-wg@BSDI.COM13. Full Copyright Statement ⚖️
Legal stuff time, but it's important, so stay with me 🎀 Everything below stays exactly as written.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. that's a wrap, bestie 🌈✨
📦 where this page comes from
- ietf: rfc2941 2000-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms