328 lines
14 KiB
Plaintext
328 lines
14 KiB
Plaintext
Network Working Group T. Ts'o, Editor
|
|
Internet-Draft Massachusetts Institute of Technology
|
|
draft-tso-telnet-krb5-04.txt April 2000
|
|
|
|
Telnet Authentication: Kerberos Version 5
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is in full conformance with
|
|
all provisions of Section 10 of RFC2026. 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 mate-
|
|
rial or to cite them other than as "work in progress."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/ietf/1id-abstracts.txt
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html.
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
|
document are to be interpreted as described in RFC 2119.
|
|
|
|
0. Abstract
|
|
|
|
This document describes how Kerberos Version 5 [1] is used with the
|
|
telnet protocol. It describes an telnet authentication sub-option
|
|
to be used with the telnet authentication option [2]. This mecha-
|
|
nism can also used to provide keying material to provide data confi-
|
|
dentiality services in conjuction with the telnet encryption option
|
|
[3].
|
|
|
|
1. Command Names and Codes
|
|
|
|
Authentication Types
|
|
|
|
KERBEROS_V5 2
|
|
|
|
Sub-option Commands
|
|
|
|
Expires Sept 2000 [Page 1]
|
|
|
|
Internet-Draft Kerberos Version 5 for Telnet April 2000
|
|
|
|
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
|
|
remote side of the connection. The first octet of the <authenti-
|
|
cation-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 cor-
|
|
rectly negotiated. The Kerberos V5 authenticator must also in-
|
|
clude the optional subkey field, which shall be filled in with a
|
|
randomly chosen key. This key shall be used for encryption pur-
|
|
poses if encryption is negotiated, and shall be used as the nego-
|
|
tiated session key (i.e., used as keyid 0) for the purposes of the
|
|
telnet encryption option; if the subkey is not filled in, then the
|
|
ticket session key will be used instead.
|
|
|
|
If data confidentiality services is desired the ENCRYPT_US-
|
|
ING_TELOPT flag must be set in the authentication-type-pair as
|
|
specified in [2].
|
|
|
|
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 au-
|
|
thentication-type-pair, the RESPONSE command must be sent before
|
|
the ACCEPT command is sent.
|
|
|
|
IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT <op-
|
|
tional 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
|
|
|
|
Expires Sept 2000 [Page 2]
|
|
|
|
Internet-Draft Kerberos Version 5 for Telnet April 2000
|
|
|
|
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 ex-
|
|
changed for the telnet session by the AUTH suboption.
|
|
|
|
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_ACCEPT IAC
|
|
SE
|
|
|
|
This command indicates that the credential forwarding was success-
|
|
ful.
|
|
|
|
IAC SB AUTHENTICATION <authentication-type-pair> FORWARD_REJECT <op-
|
|
tional reason for rejection> IAC SE
|
|
|
|
This command indicates that the credential forwarding was not suc-
|
|
cessful, 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 serv-
|
|
er 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 qual-
|
|
ified lower-case hostname of the server; and the realm is the Ker-
|
|
beros realm to which the server belongs.
|
|
|
|
Expires Sept 2000 [Page 3]
|
|
|
|
Internet-Draft Kerberos Version 5 for Telnet April 2000
|
|
|
|
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 [4]. 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 ac-
|
|
count, 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.
|
|
|
|
If forwarding has been requested, the client then sends IAC SB AU-
|
|
THENTICATION 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
|
|
|
|
Expires Sept 2000 [Page 4]
|
|
|
|
Internet-Draft Kerberos Version 5 for Telnet April 2000
|
|
|
|
[ 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 KER-
|
|
BEROS_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 KER-
|
|
BEROS_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 Sept 2000 [Page 5]
|
|
|
|
Internet-Draft Kerberos Version 5 for Telnet April 2000
|
|
|
|
IAC SB AUTHENTICATION REPLY KER-
|
|
BEROS_V5 CLIENT|MUTUAL FOR-
|
|
WARD_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. IANA Considerations
|
|
|
|
The authentication type KERBEROS_V5 and its associated suboption values
|
|
are registered with IANA. Any suboption values used to extend
|
|
the protocol as described in this document must be registered
|
|
with IANA before use. IANA is instructed not to issue new suboption
|
|
values without submission of documentation of their use.
|
|
|
|
7. Acknowledgments
|
|
|
|
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.
|
|
|
|
8. References
|
|
|
|
[1] Kohl, J. and B. Neuman, "The Kerberos Network Authentication Sys-
|
|
tem (V5)", RFC 1510, USC/Information Sciences Institute, Septem-
|
|
ber 1993.
|
|
|
|
[2] Internet Engineering Task Force, "Telnet Authentication", draft-
|
|
tso-telnet-auth-enc-04.txt, T. Ts'o, Editor, VA Linux Systems,
|
|
April 2000.
|
|
|
|
[3] Internet Engineering Task Force, "Telnet Data Encryption Option",
|
|
draft-tso-telnet-encryption-04.txt, T. Ts'o, Editor, VA Linux
|
|
Systems, April 2000.
|
|
|
|
[4] Postel, J.B. and J. Reynolds, "Telnet Option Specifications", RFC
|
|
|
|
Expires Sept 2000 [Page 6]
|
|
|
|
Internet-Draft Kerberos Version 5 for Telnet April 2000
|
|
|
|
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
|
|
|
|
Phone: (617) 253-8091
|
|
EMail: tytso@mit.edu
|
|
|
|
Expires Sept 2000 [Page 7]
|
|
|
|
|
|
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
|
|
The Kermit Project * Columbia University
|
|
612 West 115th St #716 * New York, NY * 10025
|
|
http://www.kermit-project.org/k95.html * kermit-support@kermit-project.org
|
|
|
|
|