As per Relevance of the word february, we have this rfc below:
Network Working Group D. Borman,
Request for Comments: 1416 Cray Research, Inc
Obsoletes: 1409 February 1993
Telnet Authentication
Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This RFC 1416 replaces RFC 1409, which has an important
error in the example on page 6 (one occurance of "REPLY" should
"IS").
1. Command Names and
AUTHENTICATION 37
IS 0
SEND 1
REPLY 2
NAME 3
Authentication
NULL 0
KERBEROS_V4 1
KERBEROS_V5 2
SPX 3
RSA 6
LOKI 10
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
Telnet Working Group [Page 1]
RFC 1416 Telnet Authentication Option February 1993
2. Command
This document makes reference to a "server" and a "client". For
purposes of this document, the "server" is the side of the
that did the passive TCP open (TCP LISTEN state), and the "client"
the side of the connection that did the active open
IAC WILL
The client side of the connection sends this command to
that it is willing to send and receive authentication information
IAC DO
The servers side of the connection sends this command to
that it is willing to send and receive authentication information
IAC WONT
The client side of the connection sends this command to
that it refuses to send or receive authentication information;
server side sends this command if it receives a DO
command
IAC DONT
The server side of the connection sends this command to
that it refuses to send or receive authentication information;
client side sends this command if it receives a
AUTHENTICATION command
IAC SB AUTHENTICATION SEND authentication-type-pair-list IAC
The sender of this command (the server) requests that the
side send authentication information for one of the
types listed in "authentication-type-pair-list".
"authentication-type-pair-list" is an ordered list
"authentication-type" pairs. Only the server side (
AUTHENTICATION) is allowed to send this
IAC SB AUTHENTICATION IS authentication-type-pair IAC
The sender of this command (the client) is sending
authentication information for authentication
"authentication-type-pair". Only the client side (
AUTHENTICATION) is allowed to send this
Telnet Working Group [Page 2]
RFC 1416 Telnet Authentication Option February 1993
IAC SB AUTHENTICATION REPLY authentication-type-pair
The sender of this command (the server) is sending a reply to
the authentication information received in a previous IS command
Only the server side (DO AUTHENTICATION) is allowed to send this
IAC SB AUTHENTICATION NAME remote-user IAC
This optional command is sent to specify the account name on
remote host that the user wishes to be authorized to use.
that authentication may succeed, and the authorization to use
particular account may still fail. Some authentication
may ignore this command
The "authentication-type-pair" is two octets, the first is
authentication type (as listed in Section 1, additions to this
must be registered with the Internet Assigned Numbers
(IANA)), and the second is a modifier to the type. There
currently two one bit fields defined in the modifier,
AUTH_WHO_MASK bit and the AUTH_HOW_MASK bit, so there are
possible combinations
AUTH_CLIENT_TO_
AUTH_HOW_ONE_
The client will send authentication information about the
user to the server. If the negotiation is successful,
server will have authenticated the user on the client side
the connection
AUTH_SERVER_TO_
AUTH_HOW_ONE_
The server will authenticate itself to the client. If
negotiation is successful, the client will know that it
connected to the server that it wants to be connected to
AUTH_CLIENT_TO_
AUTH_HOW_
The client will send authentication information about the
user to the server, and then the server will
itself to the client. If the negotiation is successful,
server will have authenticated the user on the client side
the connection, and the client will know that it is
to the server that it wants to be connected to
Telnet Working Group [Page 3]
RFC 1416 Telnet Authentication Option February 1993
AUTH_SERVER_TO_
AUTH_HOW_
The server will authenticate itself to the client, and then
client will authenticate itself to the server. If
negotiation is successful, the client will know that it
connected to the server that it wants to be connected to,
the server will know that the client is who it claims to be
3. Default
The default specification for this option
WONT
DONT
meaning there will not be any exchange of authentication information
4.
One of the deficiencies of the Telnet protocol is that in order
log into remote systems, users have to type their passwords,
are passed in clear text through the network. If the
goes through untrusted networks, there is the possibility
passwords will be compromised by someone watching the packets as
go by
The purpose of the AUTHENTICATION option is to provide a
for the passing of authentication information through the
session. This means that: 1) the users password will not be sent
clear text across the network, and 2) if the front end telnet
has the appropriate authentication information, it can
send the information, and the user will not have to type
password
It is intended that the AUTHENTICATION option be general enough
it can be used to pass information for any authentication system
5. Security
The ability to negotiate a common authentication mechanism
client and server is a feature of the authentication option
should be used with caution. When the negotiation is performed,
authentication has yet occurred. Therefore, each system has no
of knowing whether or not it is talking to the system it intends.
intruder could attempt to negotiate the use of an
system which is either weak, or already compromised by the intruder
Telnet Working Group [Page 4]
RFC 1416 Telnet Authentication Option February 1993
6. Implementation
WILL and DO are used only at the beginning of the connection
obtain and grant permission for future negotiations
The authentication is only negotiated in one directions; the
must send the "DO", and the client must send the "WILL".
restriction is due to the nature of authentication; there are
possible cases; server authenticates client, client
server, and server and client authenticate each other. By
negotiating the option in one direction, and then determining
of the three cases is being used via the suboption,
ambiguity is removed. If the server receives a "DO", it must
with a "WONT". If the client receives a "WILL", it must respond
a "DONT".
Once the two hosts have exchanged a DO and a WILL, the server is
to request authentication information. In the request, a list
supported authentication types is sent. Only the server may
requests ("IAC SB AUTHENTICATION SEND authentication-type-pair-
IAC SE"). Only the client may transmit authentication
via the "IAC SB AUTHENTICATION IS authentication-type ... IAC SE
command. Only the server may send replys ("IAC SB
REPLY authentication-type ... IAC SE"). As many IS and
suboptions may be exchanged as are needed for the
authentication scheme chosen
If the client does not support any of the authentication types
in the authentication-type-pair-list, a type of NULL should be
to indicate this in the IS reply. Note that in this case, the
may choose to close the connection
The order of the authentication types MUST be ordered to indicate
preference for different authentication types, the first type
the most preferred, and the last type the least preferred
The following is an example of use of the option
Client
IAC DO
IAC WILL
[ The server is now free to request authentication information
]
IAC SB AUTHENTICATION
KERBEROS_V4 CLIENT|
KERBEROS_V4 CLIENT|ONE_WAY
[ The server has requested mutual Kerberos authentication, but
Telnet Working Group [Page 5]
RFC 1416 Telnet Authentication Option February 1993
willing to do just one-way Kerberos authentication. The
will now respond with the name of the user that it wants to
in as, and the Kerberos ticket. ]
IAC SB AUTHENTICATION NAME "joe
IAC
IAC SB AUTHENTICATION
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
[ The server responds with an ACCEPT command to state that
authentication was successful. ]
IAC SB AUTHENTICATION
KERBEROS_V4 CLIENT|MUTUAL
IAC
[ Next, the client sends across a CHALLENGE to verify that it
really talking to the right server. ]
IAC SB AUTHENTICATION
KERBEROS_V4 CLIENT|
CHALLENGE xx xx xx xx xx xx
xx IAC
[ Lastly, the server sends across a RESPONSE to prove that
really is the right server
IAC SB AUTHENTICATION
KERBEROS_V4 CLIENT|
RESPONSE yy yy yy yy yy yy yy
IAC
It is expected that any implementation that supports the
AUTHENTICATION option will support all of this specification
7.
[1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
Security
Security issues are discussed in Section 5.
Telnet Working Group [Page 6]
RFC 1416 Telnet Authentication Option February 1993
Author's
David A. Borman,
Cray Research, Inc
655F Lone Oak
Eagan, MN 55123
Phone: (612) 452-6650
EMail: dab@CRAY.
Mailing List: telnet-ietf@CRAY.
Chair's
The working group can be contacted via the current chair
Steve
INTERACTIVE Systems
1901 North Naper
Naperville, IL 60563-8895
Phone: (708) 505-9100 x256
EMail: stevea@isc.
Telnet Working Group [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
