Telnet Authentication Option
obsoletes
- rfc-1416 — Telnet Authentication Option
Extracted elements (28)
Authentication is negotiated only in one direction (server sends DO, client sends WILL) to remove ambiguity: the three cases (server authenticates client, client authenticates server, mutual) are all handled via the suboption modifier bits rather than by bidirectional option negotiation.
The AUTHENTICATION option was designed to prevent cleartext password transmission, enable automatic credential submission by the front-end telnet process, and provide a path to encrypt the data stream as a side effect of successful authentication or via TELOPT ENCRYPT.
The INI_CRED_FWD_ON bit is advisory rather than imperative so that the server may delay OS-specific login procedures that depend on forwarded credentials until after those credentials have been received.
Older implementations of the telnet authentication option will not understand the ENCRYPT_MASK and INI_CRED_FWD_MASK bits. An implementation offering these bits SHOULD also offer type pairs with these bits unset if backwards compatibility is required.
This document obsoletes RFC 1416 and updates the authentication option specification so that it can be used to securely enable the telnet encryption option (RFC 2946). The primary change is the addition of ENCRYPT_MASK and INI_CRED_FWD_MASK modifier bits.
A client SHOULD NOT support the ability to turn off encryption once it has been enabled. If an attempt to re-enable encryption fails after it was disabled, the client MUST terminate the telnet connection.
A failure to successfully negotiate TELOPT ENCRYPT in either direction when ENCRYPT_USING_TELOPT was selected MUST result in immediate session termination.
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 in one-way client-to-server authentication.
Credentials SHOULD NOT be forwarded if the telnet connection is not protected using some encryption or integrity protection service.
Each side MUST verify the consistency of the auth-type-pairs in each message received; any variation in the auth-type-pair MUST be treated as a fatal protocol error.
ENCRYPT_OFF MUST be used with all AUTH types that do not provide a shared secret to be used as a session key; TELOPT ENCRYPT SHOULD NOT be negotiated in this mode.
The order of authentication types in the SEND list MUST indicate preference, with the first type being the most preferred and the last the least preferred.
The server MUST send WILL AUTHENTICATION only; if it receives DO AUTHENTICATION it must respond with WONT. The client MUST respond with DONT if it receives WILL AUTHENTICATION. Authentication is negotiated only in one direction.
The user MUST be able to specify whether authentication and encryption are to be used. There SHOULD be at least four settings: REQUIRE, PROMPT, WARN, and DISABLE, with WARN as the default for both switches.
When ENCRYPT_AFTER_EXCHANGE is used, the encryption algorithm to be used MUST be implied by the AUTH type; encryption is activated in both directions immediately after the successful exchange of the shared secret.
When ENCRYPT_USING_TELOPT is negotiated, TELOPT ENCRYPT MUST be negotiated in both directions immediately after authentication completes, and this MUST occur before credentials forwarding, other telnet option negotiations, or any user data is transmitted.
IAC SB AUTHENTICATION NAME remote-user IAC SE is an optional suboption sent by the client to specify the account name on the remote host. Authentication may succeed while authorization to use the account may still fail.
IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC SE is sent only by the server (DO side) to request that the client send authentication information for one of the listed type pairs, ordered by server preference (most preferred first).
The AUTHENTICATION telnet option is assigned code 37. Its suboption commands are IS (0), SEND (1), REPLY (2), and NAME (3). These four commands carry all authentication negotiation traffic between client and server.
The 'authentication-type-pair' is two octets: the first is the authentication type (e.g., KERBEROS_V4=1, KERBEROS_V5=2, SRP=5, DSS=14), and the second is a modifier byte encoding directional, mutual-auth, encryption, and credential-forwarding flags.
Authentication type numbers (8-bit space) and authentication modifier values are assigned by IANA under a First Come First Served policy per RFC 2434. If more than 50% of the 8-bit number space becomes allocated, IANA must refer new requests to the IESG or a designated expert. IANA must not issue values without documentation of their use.
If the selected authentication type requires encryption to be negotiated separately via TELOPT ENCRYPT (rather than as a side effect), there exists a window of vulnerability between authentication completion and the start of encryption during which an active attacker can interfere. Using ENCRYPT_USING_TELOPT eliminates this window.
Once encryption is disabled, an attacker may hijack the telnet stream and interfere with attempts to restart encryption. This is why clients should not permit encryption to be turned off and must terminate the connection if re-enabling encryption fails.
The authentication type pair must be integrity-protected at the end of the authentication exchange; each authentication type specification must define how to ensure both sides agree on the result of option negotiation. Some types may include all telnet AUTH negotiation exchanges in the integrity checksum.
The negotiation of the authentication type pair is not integrity-protected, allowing an active attacker to force selection of the weakest mutually acceptable authentication mechanism (e.g., downgrade from a strong to a 40-bit mechanism). Implementations should only accept mechanisms they trust as secure.
The username transmitted in IAC SB AUTHENTICATION NAME is not integrity-protected. Implementations should verify this value by a secure method before using it, as it is untrusted.
Authentication negotiation begins with the server sending IAC DO AUTHENTICATION and the client responding IAC WILL AUTHENTICATION. The server then sends SEND with a type-pair list; the client replies with IS; the server responds with REPLY. Multiple IS/REPLY exchanges may occur. If no type is acceptable the client uses NULL in IS; when no agreement is possible the server sends IAC DONT AUTH.
The modifier byte in an authentication-type-pair encodes five one-bit fields: AUTH_WHO_MASK (bit 0), AUTH_HOW_MASK (bit 1), INI_CRED_FWD_MASK (bit 3), and ENCRYPT_MASK (bits 2 and 4). Values: AUTH_CLIENT_TO_SERVER=0, AUTH_SERVER_TO_CLIENT=1, AUTH_HOW_ONE_WAY=0, AUTH_HOW_MUTUAL=2, ENCRYPT_OFF=0, ENCRYPT_USING_TELOPT=4, ENCRYPT_AFTER_EXCHANGE=16, INI_CRED_FWD_ON=8.