Bug 25182 - telnet client doesn't enable encryption by default
telnet client doesn't enable encryption by default
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: krb5 (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-29 08:40 EST by Need Real Name
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-01 04:00:26 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2001-01-29 08:40:40 EST
/usr/kerberos/bin/telnet client from krb5-workstation-1.2.1-8 does NOT use
encryption by default, thus it uses KRB autentication but doesn't negotiate
for encryption, at least if used for connection against KRB version IV
server (kth-krb-1.0.2 distribution).

Other packages installed on RedHat:
krbafs-utils-1.0.2-3
pam_krb5-1-19
krb5-devel-1.2.1-8
krbafs-1.0.2-3
krb5-workstation-1.2.1-8
krb5-libs-1.2.1-8

The problem is obeyed by explicit usage of option -x, I suggest recompiling
krb software with encryption enabled by default to allow maximual standard
security.
Comment 1 Nalin Dahyabhai 2001-01-29 14:40:05 EST
This would be inconsistent with the existing telnet.  Because it does not fall
back to unencrypted operation like the r-commands do, it would cause unexpected
failures for our users who don't use Kerberos, but who install it (which is a
much larger number than I'd prefer).

Much as I'd like to, for this reason, we can't change this behavior.
Comment 2 Need Real Name 2001-02-01 03:53:15 EST
Date: 30 Jan 2001 17:56:53 +0100
From: Assar Westerlund <assar@sics.se>
To: Martin MOKREJ) <mmokrejs@natur.cuni.cz>

> +This would be inconsistent with the existing telnet.  Because it
> does not fall +back to unencrypted operation like the r-commands do,
> it would cause unexpected +failures for our users who don't use
> Kerberos, but who install it (which is a +much larger number than
> I'd prefer).  + +Much as I'd like to, for this reason, we can't
> change this behavior.

That's wrong.  `vanilla telnet' doesn't support any encryption so it
isn't a problem.

/assar

--------
I agree that people who do use kerberos use the encryption and those who do NOT
use yet kerberos rely on /usr/bin/telnet so even if the /usr/kerberos/bin/telnet
would request encryption and refuse unencrypted connections, it wouldn't harm to
much. 
mmokrejs
Comment 3 Nalin Dahyabhai 2001-02-16 12:49:45 EST
It remains a problem because /usr/kerberos/bin is ahead of /usr/bin in the PATH,
in order for Kerberized r-commands to be used if they are available.  Having
/usr/kerberos/bin/telnet request encryption by default would fail unexpectedly
in many situations, and having it request encryption, but not require it, is not
good practice.

Note You need to log in before you can comment on or make changes to this bug.