dbentry_supports_enctype and 1DES enctypes
William.Fiveash at sun.com
Tue Aug 30 11:41:39 EDT 2005
On Mon, Aug 29, 2005 at 11:36:03PM -0400, Jeffrey Altman wrote:
> Telnet specifically requests a single DES session key
> because the MIT version of Telnet does not support the 3DES TELNET
> ENCRYPT option.
My point is that if the remote host service princ does not have 1DES
keys then why should the KDC issue 1DES session keys to the client that
requests a service ticket (regardless of whether it's telnet or
whatever)? I can imagine an admin thinking that by restricting the
service princ keys to some stronger enctype they would be restricting
the session keys generated by KDC for that service to that stronger
enctype. Instead, the MIT krb code hard codes issuance of 1DES session
keys if the client requests them (assuming there are no other enctype
restricting parameters in play).
Granted the permitted_enctypes parameter can be used on the server but
this is a libdefault section parameter which affects all krb'ed services
on a system.
> Note; Most people who have implemented 3DES TELNET ENCRYPT
> have gotten it wrong and providing support for it will only
> result in Telnet connections that do not work.
> Instead, if you really want to have strong encryption for Telnet
> you should use the TELNET START-TLS option that was implemented
> in C-Kermit and the SRP Telnet distribution.
I'm under the impression that ssh (which has support for krb auth via
GSS) is more secure than telnet which is what I use.
So I am not arguing that telnet needs to support stronger encryption but
rather that the KDC should not encourage it.
Sun Microsystems Inc.
Austin, TX, USA (TZ=CST6CDT)
More information about the krbdev