summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1409.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1409.txt')
-rw-r--r--doc/rfc/rfc1409.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1409.txt b/doc/rfc/rfc1409.txt
new file mode 100644
index 0000000..5fe619d
--- /dev/null
+++ b/doc/rfc/rfc1409.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group D. Borman, Editor
+Request for Comments: 1409 Cray Research, Inc.
+ January 1993
+
+
+ Telnet Authentication Option
+
+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 37
+ IS 0
+ SEND 1
+ REPLY 2
+ NAME 3
+
+ Authentication Types
+ NULL 0
+ KERBEROS_V4 1
+ KERBEROS_V5 2
+ SPX 3
+ RSA 6
+ LOKI 10
+
+ Modifiers
+ AUTH_WHO_MASK 1
+ AUTH_CLIENT_TO_SERVER 0
+ AUTH_SERVER_TO_CLIENT 1
+ AUTH_HOW_MASK 2
+ AUTH_HOW_ONE_WAY 0
+ AUTH_HOW_MUTUAL 2
+
+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.
+
+
+
+
+
+
+Telnet Working Group [Page 1]
+
+RFC 1409 Telnet Authentication Option January 1993
+
+
+ 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
+ AUTHENTICATION command.
+
+ IAC SB AUTHENTICATION 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
+ AUTHENTICATION) is allowed to send this.
+
+ IAC SB AUTHENTICATION IS authentication-type-pair <auth data> IAC SE
+
+ The sender of this command (the client) is sending the
+ authentication information for authentication type
+ "authentication-type-pair". Only the client side (WILL
+ AUTHENTICATION) is allowed to send this.
+
+ IAC SB AUTHENTICATION 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.
+
+
+
+
+
+Telnet Working Group [Page 2]
+
+RFC 1409 Telnet Authentication Option January 1993
+
+
+ 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
+ authentication type (as listed in Section 1, additions to this list
+ must be registered with the Internet Assigned Numbers Authority
+ (IANA)), 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
+ possible combinations:
+
+ 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
+ connected 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
+ itself 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
+ negotiation is successful, the client will know that it is
+ connected to the server that it wants to be connected to, and
+
+
+
+Telnet Working Group [Page 3]
+
+RFC 1409 Telnet Authentication Option January 1993
+
+
+ the server will know that the client is who it claims to be.
+
+3. Default Specification
+
+ 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 deficiencies 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
+ session. 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
+ password.
+
+ It is intended that the AUTHENTICATION option be general enough that
+ it can be used to pass information for any authentication system.
+
+5. Security Implications
+
+ 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
+ intruder could attempt to negotiate the use of an authentication
+ system which is either weak, or already compromised by the intruder.
+
+6. Implementation Rules
+
+ WILL and DO are used only at the beginning of the connection to
+ obtain 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
+
+
+
+Telnet Working Group [Page 4]
+
+RFC 1409 Telnet Authentication Option January 1993
+
+
+ restriction is due to the nature of authentication; there are three
+ possible cases; server authenticates client, client authenticates
+ server, and server and client authenticate each other. By only
+ negotiating 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
+ requests ("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"
+ command. 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
+ in as, and the Kerberos ticket. ]
+ IAC SB AUTHENTICATION NAME "joe"
+ IAC SE
+ IAC SB AUTHENTICATION IS
+ KERBEROS_V4 CLIENT|MUTUAL AUTH 4
+
+
+
+Telnet Working Group [Page 5]
+
+RFC 1409 Telnet Authentication Option January 1993
+
+
+ 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
+ AUTHENTICATION option will support all of this specification.
+
+7. References
+
+ [1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+ USC/Information Sciences Institute, July 1992.
+
+Security Considerations
+
+ Security issues are discussed in Section 5.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Telnet Working Group [Page 6]
+
+RFC 1409 Telnet Authentication Option January 1993
+
+
+Author's Address
+
+ David A. Borman, Editor
+ Cray Research, Inc.
+ 655F Lone Oak Drive
+ Eagan, MN 55123
+
+ Phone: (612) 452-6650
+ EMail: dab@CRAY.COM
+
+ Mailing List: telnet-ietf@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 [Page 7]
+ \ No newline at end of file