[3984] in Kerberos
Re: Telnet Authentication Protocol
daemon@ATHENA.MIT.EDU (Lynne Murach)
Tue Oct 4 09:40:05 1994
Date: Tue, 4 Oct 94 08:08:56 EDT
To: mattp@apertus.com
From: murach@ftp.com (Lynne Murach)
Reply-To: murach@ftp.com
Cc: kerberos@MIT.EDU
Hi,
>> I am trying to determine the standard method used for determining
>> whether a Telnet client is a kerberized client or not under K4.
>>
The advantage of the telnet protocol is that all the telnet options
are negotiated. If a telnet server supports Kerberos authentication
it will send the telnet client a "DO AUTH" telnet command. The
telnet client must respond to this telnet option. If the telnet
client supports Kerberos authentication it will respond with
a "WILL AUTH". If the telnet client does not support Kerberos
authentication, it will respond with a "WONT AUTH". At this point
the telnet server knows how to respond. If it received a "WILL
AUTH", telnet suboption negotiations for Kerberos authentication
will begin. If it received a "WONT AUTH", it will know the telnet
client can't do any Kerberos authentication and respond appropriately.
>> I see that there is a telnetd in which the rfc1416 protocol is implemented.
>> This provides a straigtforward way by just asking the client whether they
>> are kerberized or not through Telnet negotiation.
Correct. The *only* way the telnet server can receive any telnet
Kerberos authentication information is through telnet option
negotiations. The telnet options can be sent in any order, but
all the telnet Kerberos authentication information is done through
telnet option negotiations.
>> However, it appears that in the MIT K4 distribution the bsd apps and the
>> sample apps do not do any handshaking prior to issuing a krb_recvauth().
>> Is this the standard technique? Does the server issue a krb_recvauth()
>> and if there is no response within a certain time or the response is
>> invalid ticket information (as would be the case if a non-kerberized
>> client sent normal data instead of authentication data) disconnect the
>> client? Is this the standard?
>>
>> Put another way, how is the Telnet end-server to know that authentication data
>> is on its way and not some other data?
The telnet server knows that authentication information is on its
way through the telnet option negotiations. The authentication
information will be included in a telnet command like "AUTH IS
K4 CLIENT| MUTUAL AUTH 4 7 1 ...." The order that the options
are negotiated is not important as long as the telnet client
responds to all the options that were requested by the telnet
server.
On a different note, I have seen some telnet servers (Sandia's)
which have a timeout value and will close the telnet connection
after a certain amount of time *even* if the telnet options are
in the process of being negotiated. This is especially bothersome
when doing telnet encryption option negotiations which have a
number of suboption negotiations. The telnet server should realize
that authentication has succeeded and encryption option negotiations
are almost complete, but it just closes the connection after a
certain time if authentication and encryption are not completely
negotiated successfully. I guess the best way around this is
to send the telnet authentication and encryption information
at the beginning of the telnet option negotiations.
Hope this helps,
Lynne Murach
ftp Software Inc.
murach@ftp.com
