Network Working Group T. Ts'o, Editor
Internet-Draft Massachusetts Institute of Technology
draft-tso-telnet-krb5-00.txt February 1998
Telnet Authentication: Kerberos Version 5
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
1. Command Names and Codes
Authentication Types
KERBEROS_V5 2
Sub-option Commands
AUTH 0
REJECT 1
ACCEPT 2
RESPONSE 3
FORWARD 4
FORWARD_ACCEPT 5
FORWARD_REJECT 6
2. Command Meanings
IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH <Kerberos V5
KRB_AP_REQ message> IAC SE
This is used to pass the Kerberos V5 [1] KRB_AP_REQ message to the
Expires August 1998 [Page 1]
Internet-Draft Kerberos Version 5 for Telnet February 1998
remote side of the connection. The first octet of the
<authentication-type-pair> value is KERBEROS_V5, to indicate that
Version 5 of Kerberos is being used. The Kerberos V5
authenticator in the KRB_AP_REQ message must contain a Kerberos V5
checksum of the two-byte authentication type pair. This checksum
must be verified by the server to assure that the authentication
type pair was correctly negotiated. The Kerberos V5 authenticator
must also include the optional subkey field, which shall be filled
in with a randomly chosen key. This key shall be used for
encryption purposes if encryption is negotiated, and shall be
assigned keyid 0 for the purposes of the telnet encryption option.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT IAC SE
This command indicates that the authentication was successful.
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.
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.
IAC SB AUTHENTICATION REPLY <authentication-type-pair> RESPONSE
<KRB_AP_REP message> IAC SE
This command is used to perform mutual authentication. It is only
used when the AUTH_HOW_MUTUAL bit is set in the second octet of
the authentication-type-pair. After an AUTH command is verified,
a RESPONSE command is sent which contains a Kerberos V5 KRB_AP_REP
message to perform the mutual authentication.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD <KRB_CRED
message> IAC SE
This command is used to forward kerberos credentials for use by
the remote session. The credentials are passed as a Kerberos V5
KRB_CRED message which includes, among other things, the forwarded
Kerberos ticket and a session key associated with the ticket. Part
of the KRB_CRED message is encrypted in the key previously
exchanged for the telnet session by the AUTH subobption.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
SE
This command indicates that the credential forwarding was
Expires August 1998 [Page 2]
Internet-Draft Kerberos Version 5 for Telnet February 1998
successful.
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT
<optional reason for rejection> IAC SE
This command indicates that the credential forwarding 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.
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, the
server will send a RESPONSE before it sends the ACCEPT.
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.
In addition, if the AUTH_HOW bit is set to AUTH_HOW_MUTUAL, the
client will send a RESPONSE before it sends the ACCEPT.
The Kerberos principal used by the server will generally be of the
form "host/<hostname>@realm". That is, the first component of the
Kerberos principal is "host"; the second component is the fully
qualified lower-case hostname of the server; and the realm is the
Kerberos realm to which the server belongs.
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 [2]. Otherwise the following
byte might be mis-interpreted as a Telnet command.
4. Examples
User "joe" may wish to log in as user "pete" on machine "foo". If
"pete" has set things up on "foo" to allow "joe" access to his
account, then the client would send IAC SB AUTHENTICATION NAME "pete"
IAC SE IAC SB AUTHENTICATION IS KERBEROS_V5 AUTH <KRB_AP_REQ_MESSAGE>
IAC SE
The server would then authenticate the user as "joe" from the
KRB_AP_REQ_MESSAGE, and if the KRB_AP_REQ_MESSAGE was accepted by
Kerberos, and if "pete" has allowed "joe" to use his account, the
server would then continue the authentication sequence by sending a
RESPONSE (to do mutual authentication, if it was requested) followed
by the ACCEPT.
Expires August 1998 [Page 3]
Internet-Draft Kerberos Version 5 for Telnet February 1998
If forwarding has been requested, the client then sends IAC SB
AUTHENTICATION IS KERBEROS_V5 CLIENT|MUTUAL FORWARD <KRB_CRED
structure with credentials to be forwarded> IAC SE. If the server
succeeds in reading the forwarded credentials, the server sends
FORWARD_ACCEPT else, a FORWARD_REJECT is sent back.
Client Server
IAC DO AUTHENTICATION
IAC WILL AUTHENTICATION
[ The server is now free to request authentication information.
]
IAC SB AUTHENTICATION SEND
KERBEROS_V5 CLIENT|MUTUAL
KERBEROS_V5 CLIENT|ONE_WAY IAC
SE
[ The server has requested mutual Version 5 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_V5 CLIENT|MUTUAL AUTH
<KRB_AP_REQ message> IAC SE
[ Since mutual authentication is desired, the server sends across
a RESPONSE to prove that it really is the right server. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
RESPONSE <KRB_AP_REP message>
IAC SE
[ The server responds with an ACCEPT command to state that the
authentication was successful. ]
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL ACCEPT
IAC SE
[ If so requested, the client now sends the FORWARD command to
forward credentials to the remote site. ]
IAC SB AUTHENTICATION IS
Expires August 1998 [Page 4]
Internet-Draft Kerberos Version 5 for Telnet February 1998
KERBEROS_V5 CLIENT|MUTUAL
FORWARD <KRB_CRED message> IAC
SE
[ The server responds with a FORWARD_ACCEPT command to state that
the credential forwarding was successful. ]
Expires August 1998 [Page 5]
Internet-Draft Kerberos Version 5 for Telnet February 1998
IAC SB AUTHENTICATION REPLY
KERBEROS_V5 CLIENT|MUTUAL
FORWARD_ACCEPT IAC SE
5. Security Considerations
The selection of the random session key in the Kerberos V5 authenti-
cator is critical, since this key will be used for encrypting the
telnet data stream if encryption is enabled. It is strongly advised
that the random key selection be done using cryptographic techniques
that involve the Kerberos ticket's session key. For example, using
the current time, encrypting it with the ticket session key, and then
correcting for key parity is a strong way to generate a subsession
key, since the ticket session key is assumed to be never disclosed to
an attacker.
Care should be taken before forwarding a user's Kerberos credentials
to the remote server. If the remote server is not trustworthy, this
could result in the user's credentials being compromised. Hence, the
user interface should not forward credentials by default; it would be
far safer to either require the user to explicitly request creden-
tials forwarding for each connection, or to have a trusted list of
hosts for which credentials forwarding is enabled, but to not enable
credentials forwarding by default for all machines.
6. Acknowledgements
This document was originally written by Dave Borman of Cray Research,
Inc. Theodore Ts'o of MIT revised it to reflect the latest implemen-
tation experience. Cliff Neuman and Prasad Upasani of USC's Informa-
tion Sciences Institute developed the credential forwarding support.
In addition, the contributions of the Telnet Working Group are also
gratefully acknowledged.
7. References
[1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
tem (V5)", RFC 1510, USC/Information Sciences Institute, Sep-
tember 1993.
[2] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
855, STD 8, USC/Information Sciences Institute, May 1983.
Editor's Address
Theodore Ts'o
Massachusetts Institute of Technology
MIT Room E40-343
77 Massachusetts Avenue
Cambridge, MA 02139
Expires August 1998 [Page 6]
Internet-Draft Kerberos Version 5 for Telnet February 1998
Phone: (617) 253-8091
EMail: tytso@mit.edu
Expires August 1998 [Page 7]