Kerberizing a non-kerberized telnet client

[Jeffrey Altman]

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