464 lines
17 KiB
Plaintext
464 lines
17 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
Network Working Group Internet Engineering Task Force
|
||
Internet-Draft Telnet Working Group
|
||
Cray Research, Inc.
|
||
D. Borman, Editor
|
||
July 1992
|
||
|
||
|
||
Telnet Authentication Option with Encryption
|
||
|
||
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."
|
||
|
||
Please check the 1id-abstracts.txt listing contained in the
|
||
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
|
||
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
|
||
current status of any Internet Draft.
|
||
|
||
1. Command Names and Codes
|
||
|
||
AUTHENTICATION 39
|
||
IS 0
|
||
SEND 1
|
||
REPLY 2
|
||
NAME 3
|
||
AUTH 4
|
||
ENCRYPT 5
|
||
|
||
Authentication Types
|
||
NULL 0
|
||
KERBEROS_V4 1
|
||
KERBEROS_V5 2
|
||
SPX 3
|
||
RSA 6
|
||
LOKI 10
|
||
|
||
Modifiers
|
||
AUTH_WHO_MASK 1
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 1]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
AUTH_CLIENT_TO_SERVER 0
|
||
AUTH_SERVER_TO_CLIENT 1
|
||
|
||
AUTH_HOW_MASK 2
|
||
AUTH_HOW_ONE_WAY 0
|
||
AUTH_HOW_MUTUAL 2
|
||
|
||
AUTH_ENCRYPT_MASK4 XXX
|
||
AUTH_ENCRYPT_NO0 XXX
|
||
AUTH_ENCRYPT_YES4 XXX
|
||
|
||
2. Command Meanings
|
||
|
||
This document makes reference to a "server" and a "client". For the
|
||
purposes of this document, the "server" is the side of the connection
|
||
that did the passive TCP open (TCP LISTEN state), and the "client" is
|
||
the side of the connection that did the active open.
|
||
|
||
IAC WILL AUTHENTICATION
|
||
|
||
The client side of the connection sends this command to indicate
|
||
that it is willing to send and receive authentication information.
|
||
|
||
IAC DO AUTHENTICATION
|
||
|
||
The servers side of the connection sends this command to indicate
|
||
that it is willing to send and receive authentication information.
|
||
|
||
IAC WONT AUTHENTICATION
|
||
|
||
The client side of the connection sends this command to indicate
|
||
that it refuses to send or receive authentication information; the
|
||
server side sends this command if it receives a DO AUTHENTICATION
|
||
command.
|
||
|
||
IAC DONT AUTHENTICATION
|
||
|
||
The server side of the connection sends this command to indicate
|
||
that it refuses to send or receive authentication information; the
|
||
client side sends this command if it receives a WILL AUTHENTICA-
|
||
TION command.
|
||
|
||
IAC SB AUTHENTICATION AUTH SEND authentication-type-pair-list IAC SE
|
||
|
||
The sender of this command (the server) requests that the remote
|
||
side send authentication information for one of the authentication
|
||
types listed in "authentication-type-pair-list". The
|
||
"authentication-type-pair-list" is an ordered list of
|
||
"authentication-type" pairs. Only the server side (DO AUTHENTICA-
|
||
TION) is allowed to send this.
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 2]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
IAC SB AUTHENTICATION ENCRYPT SEND encryption-type-pair-list IAC SE
|
||
|
||
The sender of this command is stating what types of encryption it
|
||
will support. Only the server side (DO AUTHENTICATION) is allowed
|
||
to send this. The current types of encryption are listed in the
|
||
current version of the Assigned Numbers document[1].
|
||
|
||
IAC SB AUTHENTICATION AUTH IS authentication-type-pair <auth data>
|
||
IAC SE
|
||
|
||
The sender of this command (the client) is sending the authentica-
|
||
tion information for authentication type "authentication-type-
|
||
pair". Only the client side (WILL AUTHENTICATION) is allowed to
|
||
send this.
|
||
|
||
IAC SB AUTHENTICATION ENCRYPT IS encryption-type ... IAC SE
|
||
|
||
The sender of this command is stating what type of encryption to
|
||
use, and any initial data that is needed Only the client side of
|
||
the connection (WILL AUTHENTICATION) may send the IS command. to
|
||
initialize the encryption-type scheme.
|
||
|
||
IAC SB AUTHENTICATION AUTH REPLY authentication-type-pair <auth data>
|
||
IAC SE
|
||
|
||
The sender of this command (the server) is sending a reply to the
|
||
the authentication information received in a previous IS command.
|
||
Only the server side (DO AUTHENTICATION) is allowed to send this.
|
||
|
||
IAC SB AUTHENTICATION ENCRYPT REPLY encryption-type ... IAC SE
|
||
|
||
The sender of this command is continuing the initial data exchange
|
||
that is needed to initialize the encryption-type scheme. Only the
|
||
server side of the connection (DO AUTHENTICATION) may send the IS
|
||
command.
|
||
|
||
IAC SB AUTHENTICATION NAME remote-user IAC SE
|
||
|
||
This optional command is sent to specify the account name on the
|
||
remote host that the user wishes to be authorized to use. Note
|
||
that authentication may succeed, and the authorization to use a
|
||
particular account may still fail. Some authentication mechanisms
|
||
may ignore this command.
|
||
|
||
|
||
The "authentication-type-pair" is two octets, the first is the au-
|
||
thentication type, and the second is a modifier to the type. There
|
||
are currently two one bit fields defined in the modifier, the
|
||
AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit, so there are four possi-
|
||
ble combinations:
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 3]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
AUTH_CLIENT_TO_SERVER
|
||
AUTH_HOW_ONE_WAY
|
||
|
||
The client will send authentication information about the local
|
||
user to the server. If the negotiation is successful, the
|
||
server will have authenticated the user on the client side of
|
||
the connection.
|
||
|
||
AUTH_SERVER_TO_CLIENT
|
||
AUTH_HOW_ONE_WAY
|
||
|
||
The server will authenticate itself to the client. If the
|
||
negotiation is successful, the client will know that it is con-
|
||
nected to the server that it wants to be connected to.
|
||
|
||
AUTH_CLIENT_TO_SERVER
|
||
AUTH_HOW_MUTUAL
|
||
|
||
The client will send authentication information about the local
|
||
user to the server, and then the server will authenticate it-
|
||
self to the client. If the negotiation is successful, the
|
||
server will have authenticated the user on the client side of
|
||
the connection, and the client will know that it is connected
|
||
to the server that it wants to be connected to.
|
||
|
||
AUTH_SERVER_TO_CLIENT
|
||
AUTH_HOW_MUTUAL
|
||
|
||
The server will authenticate itself to the client, and then the
|
||
client will authenticate itself to the server. If the negotia-
|
||
tion is successful, the client will know that it is connected
|
||
to the server that it wants to be connected to, and the server
|
||
will know that the client is who it claims to be.
|
||
|
||
|
||
IAC SB ENCRYPT START keyid IAC SE
|
||
|
||
The sender of this command is stating that at this point in the data
|
||
stream, all following data will be encrypted, via the previously
|
||
negotiated method of data encryption. Only the client side of the
|
||
connection (WILL AUTHENTICATION) may send the START command.
|
||
|
||
The keyid is a variable length field. It may be used by various en-
|
||
cryption mechanisms to identify which encryption key is to be used,
|
||
when multiple encryption keys might be known on either side of the
|
||
connection. The keyid field is encoded with the most significant
|
||
byte first, and a keyid value of zero is reserved to indicate the de-
|
||
fault encryption key derived during the authentication process. The
|
||
keyid field must be at least one byte long.
|
||
3. Default Specification
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 4]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
The default specification for this option is
|
||
|
||
WONT AUTHENTICATION
|
||
DONT AUTHENTICATION
|
||
|
||
meaning there will not be any exchange of authentication information.
|
||
|
||
4. Motivation
|
||
|
||
One of the deficiences of the Telnet protocol is that in order to log
|
||
into remote systems, users have to type their passwords, which are
|
||
passed in clear text through the network. If the connections goes
|
||
through untrusted networks, there is the possibility that passwords
|
||
will be compromised by someone watching the packets as they go by.
|
||
|
||
The purpose of the AUTHENTICATION option is to provide a framework
|
||
for the passing of authentication information through the TELNET ses-
|
||
sion. This means that: 1) the users password will not be sent in
|
||
clear text across the network, and 2) if the front end telnet process
|
||
has the appropriate authentication information, it can automatically
|
||
send the information, and the user will not have to type any pass-
|
||
word.
|
||
|
||
It is intended that the AUTHENTICATION option be general enough that
|
||
it can be used to pass information for any authentication system.
|
||
|
||
Additionally, other sensitive information be communicated via the
|
||
TELNET data stream. By negotiating the use of data encryption during
|
||
the authentication process, the user can ensure that session data
|
||
cannot be intercepted as it traverses the network.
|
||
|
||
5. Security Considerations
|
||
|
||
The ability to negotiate a common authentication mechanism between
|
||
client and server is a feature of the authentication option that
|
||
should be used with caution. When the negotiation is performed, no
|
||
authentication has yet occurred. Therefore each system has no way of
|
||
knowing whether or not it is talking to the system it intends. An in-
|
||
truder could attempt to negotiate the use of an authentication system
|
||
which is either weak, or already compromised by the intruder.
|
||
|
||
The use of encryption is intended to provide protection against pas-
|
||
sive attacks, not against active attacks. In other words, the en-
|
||
cryption can be used to provide protection from someone who is just
|
||
watching the IP packets as they pass through the network, but may not
|
||
from someone who is able to modify packets in flight. This is not to
|
||
say that the use of encryption doesn't provide any protection against
|
||
an active attacker, but that additional code and steps would have to
|
||
be done in order to provide compelete protection from an active at-
|
||
tacker.
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 5]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
6. Implementation Rules
|
||
|
||
WILL and DO are used only at the beginning of the connection to ob-
|
||
tain and grant permission for future negotiations.
|
||
|
||
The authentication is only negotiated in one directions; the server
|
||
must send the "DO", and the client must send the "WILL". This res-
|
||
triction is due to the nature of authentication; there are three pos-
|
||
sible cases; server authenticates client, client authenticates
|
||
server, and server and client authenticate each other. By only nego-
|
||
tiating the option in one direction, and then determining which of
|
||
the three cases is being used via the suboption, potential ambiguity
|
||
is removed. If the server receives a "DO", it must respond with a
|
||
"WONT". If the client receives a "WILL", it must respond with a
|
||
"DONT".
|
||
|
||
Once the two hosts have exchanged a DO and a WILL, the server is free
|
||
to request authentication information. In the request, a list of
|
||
supported authentication types is sent. Only the server may send re-
|
||
quests ("IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC
|
||
SE"). Only the client may transmit authentication information via
|
||
the "IAC SB AUTHENTICATION IS authentication-type ... IAC SE" com-
|
||
mand. Only the server may send replys ("IAC SB AUTHENTICATION REPLY
|
||
authentication-type ... IAC SE"). As many IS and REPLY suboptions
|
||
may be exchanged as are needed for the particular authentication
|
||
scheme chosen.
|
||
|
||
If the client does not support any of the authentication types listed
|
||
in the authentication-type-pair-list, a type of NULL should be used
|
||
to indicate this in the IS reply. Note that in this case, the server
|
||
may choose to close the connection.
|
||
|
||
The order of the authentication types MUST be ordered to indicate a
|
||
preference for different authentication types, the first type being
|
||
the most preferred, and the last type the least preferred.
|
||
|
||
The following is an example of use of the option:
|
||
|
||
Client Server
|
||
IAC DO AUTHENTICATION
|
||
IAC WILL AUTHENTICATION
|
||
[ The server is now free to request authentication information.
|
||
]
|
||
IAC SB AUTHENTICATION SEND
|
||
KERBEROS_V4 CLIENT|MUTUAL
|
||
KERBEROS_V4 CLIENT|ONE_WAY IAC
|
||
SE
|
||
[ The server has requested mutual Kerberos authentication, but is
|
||
willing to do just one-way Kerberos authentication. The client
|
||
will now respond with the name of the user that it wants to log
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 6]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
in as, and the Kerberos ticket. ]
|
||
IAC SB AUTHENTICATION NAME "joe"
|
||
IAC SE
|
||
IAC SB AUTHENTICATION IS
|
||
KERBEROS_V4 CLIENT|MUTUAL AUTH 4
|
||
7 1 67 82 65 89 46 67 7 9 77 0
|
||
48 24 49 244 109 240 50 208 43
|
||
35 25 116 104 44 167 21 201 224
|
||
229 145 20 2 244 213 220 33 134
|
||
148 4 251 249 233 229 152 77 2
|
||
109 130 231 33 146 190 248 1 9
|
||
31 95 94 15 120 224 0 225 76 205
|
||
70 136 245 190 199 147 155 13
|
||
IAC SE
|
||
[ The server responds with an ACCEPT command to state that the
|
||
authentication was successful. ]
|
||
IAC SB AUTHENTICATION REPLY
|
||
KERBEROS_V4 CLIENT|MUTUAL ACCEPT
|
||
IAC SE
|
||
[ Next, the client sends across a CHALLENGE to verify that it is
|
||
really talking to the right server. ]
|
||
IAC SB AUTHENTICATION REPLY
|
||
KERBEROS_V4 CLIENT|MUTUAL
|
||
CHALLENGE xx xx xx xx xx xx xx
|
||
xx IAC SE
|
||
[ Lastly, the server sends across a RESPONSE to prove that it
|
||
really is the right server.
|
||
IAC SB AUTHENTICATION REPLY
|
||
KERBEROS_V4 CLIENT|MUTUAL
|
||
RESPONSE yy yy yy yy yy yy yy yy
|
||
IAC SE
|
||
|
||
It is expected that any implementation that supports the Telnet AU-
|
||
THENTICATION option will support all of this specification.
|
||
|
||
7. References
|
||
|
||
|
||
[1] Reynolds, Joyce, and Postel, Jon, "Assigned Numbers", RFC 1340,
|
||
ISI, July 1992
|
||
|
||
|
||
Author's Address
|
||
|
||
David A. Borman, Editor
|
||
Cray Research, Inc.
|
||
655F Lone Oak Drive
|
||
Eagan, MN 55123
|
||
|
||
Phone: (612) 452-6650
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 7]
|
||
|
||
Internet-DraftTelnet Authentication Option with Encryption July 1992
|
||
|
||
|
||
Mailing List: telnet-ietf@CRAY.COM
|
||
EMail: dab@CRAY.COM
|
||
|
||
Chair's Address
|
||
|
||
The working group can be contacted via the current chair:
|
||
|
||
Steve Alexander
|
||
INTERACTIVE Systems Corporation
|
||
1901 North Naper Boulevard
|
||
Naperville, IL 60563-8895
|
||
|
||
Phone: (708) 505-9100 x256
|
||
EMail: stevea@isc.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Telnet Working Group Expires January 1993 [Page 8]
|
||
|