[12706] in Athena Bugs
Re: telnet -safe or -x behaves DANGEROUSLY
daemon@ATHENA.MIT.EDU (John Hawkinson)
Wed Oct 5 17:35:08 1994
To: brlewis@MIT.EDU
Cc: jhawk@MIT.EDU, bugs@MIT.EDU, yandros@MIT.EDU, hobbit@asylum.sf.ca.us,
jhawk@MIT.EDU, kannan@MIT.EDU (Is this you?)
In-Reply-To: Your message of "Wed, 05 Oct 1994 11:32:30 EDT."
<9410051532.AA14304@joy.MIT.EDU>
Date: Wed, 05 Oct 1994 17:34:55 EDT
From: John Hawkinson <jhawk@MIT.EDU>
In message <9410051532.AA14304@joy.MIT.EDU>, brlewis@mit.edu writes:
[para's flipflopped]
>The issue remains that we can't control all telnet clients (e.g. NCSA
>telnet for Mac), so users must be educated to look for "What you type is
>protected by encryption" before they type their passwords.
Sure. Granted.
>Try "add telnet; ktelnet -safe" to see if it gives the behavior you
>want. I submitted a patch ([12462] in the bugs discuss meeting) that
>does the right thing, but it was too late to get that patch into release
>7.7.
Unfortunately, this patch (you call a patch to the Makefile a patch?
:-)) doesn't cut it.
In [12462] of bugs you said:
> Hmm...it's awfully hard to trace the program flow of ktelnet's
> authentication mechanism, but after 45 minutes of hunting, I find that
> -DKANNAN would give the behavior Gildea wants, which does seem
> appropriate.
[I'm looking at the 7.7 sources in /afs/dev; should I instead be
looking in the telnet locker or somesuch?]
This is presumably a patch by Kannan Alagappan (?). Anyway, it looks
like this:
> if (auth_debug_mode)
> printf(">>>%s: Sent failure message\r\n", Name);
> auth_finished(0, AUTH_REJECT);
> #ifdef KANNAN
> /*
> * We requested strong authentication, however no mechanisms worked.
> * Therefore, exit on client end.
> */
> printf("Unable to securely authenticate user ... exit\n");
> exit(0);
> #endif /* KANNAN */
>
>
> }
The problem here is that this only happens if telnet gets that far.
In general, telnet will only get there if the server supports
Kerberos, and fails to authenticate for some reason (Principal unknown,
no ticket file, etc., etc.). This does NOT happen if the other side
doesn't support Kerberos authentication in the first place.
You can easily see this because the stuff just before KANNAN should
print
>>>TELNET: Sent failure message
If you've ``toggle authdebug''ed before opening. As in my initial
bug report, if the other end just doesn't support Kerberos, this is
no good (it's almost worse, as such problems scale. You fix it for the
uncommon case, but not for the common case).
Since you claim O(45m) to trace code paths, I'll try and come up
w/ a better patch, but I'll do it later today...
--jhawk
