Telnet Authentication: Kerberos Version 5
Extracted elements (20)
If the subkey field is not filled in, the ticket session key will be used instead as the session key for telnet encryption. The subkey is preferred because it is randomly chosen per-connection, providing better forward secrecy than reusing the ticket session key.
A user may log in as a different user than the Kerberos principal by sending 'IAC SB AUTHENTICATION NAME <username> IAC SE' before the AUTH command. The server authenticates the Kerberos identity but uses the NAME to determine account access if permitted.
Any Telnet IAC characters that occur in the KRB_AP_REQ or KRB_AP_REP messages, the KRB_CRED structure, or the optional rejection text string must be doubled as specified in RFC 855, to prevent mis-interpretation as Telnet commands.
If data confidentiality services are desired, the ENCRYPT_USING_TELOPT flag must be set in the authentication-type-pair as specified in RFC 2941.
If the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair, the RESPONSE command must be sent before the ACCEPT command is sent.
The Kerberos principal used by the server will generally be of the form 'host/<hostname>@realm', where the hostname is the fully qualified lower-case hostname of the server.
The Kerberos V5 authenticator in the KRB_AP_REQ message must contain a Kerberos V5 checksum of the two-byte authentication type pair, and this checksum must be verified by the server to assure the authentication type pair was correctly negotiated.
The Kerberos V5 authenticator must include the optional subkey field filled in with a randomly chosen key. This key shall be used for encryption if encryption is negotiated, and shall serve as the negotiated session key (keyid 0) for the telnet encryption option.
Authentication type KERBEROS_V5 is assigned the code value 2. Sub-option commands are: AUTH=0, REJECT=1, ACCEPT=2, RESPONSE=3, FORWARD=4, FORWARD_ACCEPT=5, FORWARD_REJECT=6.
FORWARD_ACCEPT indicates successful credential forwarding. FORWARD_REJECT indicates failure, with optional ASCII text reason in the suboption data.
The ACCEPT sub-option 'IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE' indicates successful authentication. If AUTH_HOW_MUTUAL is set in the authentication-type-pair, a RESPONSE command must be sent before ACCEPT.
The FORWARD sub-option carries a KRB_CRED message to forward Kerberos credentials to the remote session. Part of the KRB_CRED message is encrypted with the key previously exchanged via the AUTH suboption.
The REJECT sub-option 'IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <optional reason> IAC SE' indicates failed authentication; any additional sub-option data is an ASCII text message explaining the rejection.
The RESPONSE sub-option carries a KRB_AP_REP message for mutual authentication: 'IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE <KRB_AP_REP message> IAC SE'. It is only used when AUTH_HOW_MUTUAL is set.
The authentication type KERBEROS_V5 (value 2) and its associated suboption values (AUTH=0, REJECT=1, ACCEPT=2, RESPONSE=3, FORWARD=4, FORWARD_ACCEPT=5, FORWARD_REJECT=6) are registered with IANA. New suboption values require documentation submission before IANA will assign them.
Credential forwarding poses a risk if the remote server is untrustworthy. The user interface should not forward credentials by default; users should explicitly request forwarding per-connection or a trusted-host list should control it.
The 'IAC SB AUTHENTICATION NAME name IAC SE' message is unprotected in this protocol. Its contents must be verified by a secure method after authentication completes before the name is used for authorization decisions.
The random session key in the Kerberos V5 authenticator is critical for telnet encryption. It is strongly advised to generate it using the ticket session key cryptographically (e.g., encrypting current time with the ticket session key and correcting for key parity), since the ticket session key is assumed never disclosed to an attacker.
Auth direction is controlled by the AUTH_WHO bit: if AUTH_CLIENT_TO_SERVER, client sends AUTH and server responds with ACCEPT or REJECT (plus RESPONSE if mutual); if AUTH_SERVER_TO_CLIENT, server sends AUTH and client responds. In mutual mode, RESPONSE precedes ACCEPT from whichever side responds.
The AUTH sub-option carries a Kerberos V5 KRB_AP_REQ message: 'IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <KRB_AP_REQ message> IAC SE'. The first octet of authentication-type-pair must be KERBEROS_V5 (2).