Network Working Group S. Alexander, Editor Internet-Draft Lachman Technology, Inc. <draft-ietf-telnet-authker-v5-01.txt> November 1993
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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.''
To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au.
Distribution of this memo is unlimited.
Authentication Types
KERBEROS_V5 2
Sub-option Commands
AUTH 0
REJECT 1
ACCEPT 2
RESPONSE 3
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 May 1994 [Page 1]
<authentication-type-pair> value is KERBEROS_V5, to indicate that
Version 5 of Kerberos is being used.
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.
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 and KRB_AP_REP messages must be doubled as specified in [2]. Otherwise the
Expires May 1994 [Page 2]
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.
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
Expires May 1994 [Page 3]
IAC SB AUTHENTICATION REPLY KERBEROS_V5 CLIENT|MUTUAL ACCEPT IAC SE
Expires May 1994 [Page 4]
This document was originally written by Dave Borman of Cray Research, Inc. Theodore Ts'o of MIT revised it to reflect the latest implementation experience. The contributions of the Telnet Working Group are also gratefully acknowledged.
[1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, USC/Information Sciences Institute, September 1993.
[2] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC 855, STD 8, USC/Information Sciences Institute, May 1983.
Steve Alexander
Lachman Technology, Inc.
1901 North Naper Boulevard
Naperville, IL 60563-8895
Phone: (708) 505-9555 x256
EMail: stevea@lachman.com
Expires May 1994 [Page 5]