Browse Prior Art Database

Telnet Authentication: Kerberos Version 4 (RFC1411) Disclosure Number: IPCOM000002237D
Original Publication Date: 1993-Jan-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 4 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Borman: AUTHOR

Related Documents

10.17487/RFC1411: DOI


This memo defines an Experimental Protocol for the Internet community.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 44% of the total text.

Network Working Group D. Borman, Editor Request for Comments: 1411 Cray Research, Inc. January 1993

Telnet Authentication: Kerberos Version 4

Status of this Memo

This memo defines an Experimental Protocol for the Internet community. Discussion and suggestions for improvement are requested. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.

1. Command Names and Codes

Authentication Types


Suboption Commands


2. Command Meanings

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, to indicate the usage of Kerberos version 4.


This command indicates that the authentication was successful.

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

This command indicates that the authentication was not successful, and if there is any more data in the sub-option, it is an ASCII text message of the reason for the rejection.

Telnet Working Group [Page 1]

RFC 1411 Kerberos Version 4 for Telnet January 1993

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 perform mutual authentication. They are only used when the AUTH_HOW_MUTUAL bit is set in the second octet of the authentication-type-pair. After successfully sending an AUTH and receiving an ACCEPT, 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 is sent, the "encrypted challenge" is the 8-byte-challenge encrypted in the session key. When the CHALLENGE command is received, the contents are decrypted to get the original 8-byte- challenge, this value is then incremented by one, re-encrypted with the session key, and returned as the "encrypted response" in the RESPONSE command. The receiver of the RESPONSE command decrypts the "encrypted response", and verifies that the resultant value is the original 8-byte-challenge incremented by one.

The "encrypted challenge" value sent/received in the CHALLENGE command is also encrypted with the session key on both sides of the session, to produce a random 8-byte key to be 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. In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, a...