Kerberizing a non-kerberized telnet client
Jeffrey Altman
jaltman2 at nyc.rr.com
Sat May 15 09:08:35 EDT 2004
Paul Vixie wrote:
>>... The problem is we use a non-kerberized telnet client in the field.
>>We are heavily dependant on this client, meaning we can not change
>>clients and fyi, there are no kerberized upgrade for this client. Is
>>there a way to "wrap" a non-kerberized telnet client so it will use
>>kerberos authentication? ...
>
>
> that depends on what benefits you're willing to forego. your non-kerberized
> telnet client is probably not encrypting the session, so if you have to type
> your kerberos password it will be in the clear, which is bad. (it seems
> unlikely that it will be able to use ticket passing to avoid this typing
> of passwords, since it's not a kerberized telnet client.)
The decision to prompt for a password is determined by the server and
not the client. If the protocol wrapper properly implements AUTH KRB5
and AUTH ENCRYPT or the combination of START-TLS and AUTH KRB5 there
would be an encrypted channel for the non-kerberized telnet client to use.
Jeffrey Altman
--
-----------------
This e-mail account is not read on a regular basis.
Please send private responses to jaltman at mit dot edu
More information about the Kerberos
mailing list