[13299] in Athena Bugs
Re: telnet
daemon@ATHENA.MIT.EDU (brlewis@MIT.EDU)
Mon Mar 6 17:43:12 1995
From: brlewis@MIT.EDU
Date: Mon, 6 Mar 95 17:42:54 -0500
To: Theodore Ts'o <tytso@MIT.EDU>
Cc: John Hawkinson <jhawk@MIT.EDU>, Chris Shabsin <shabby@MIT.EDU>,
bugs@MIT.EDU
In-Reply-To: "[13293] in Athena Bugs"
In this instance, I side with jhawk. But maybe I can say more clearly
what he's trying to say.
The telnet protocol misnamed the AUTHENTICATION option.
It should have been called the AUTHENTICATION_AND_AUTHORIZATION option.
If you authenticate properly but aren't authorized to autologin, the
"AUTHENTICATION" option fails. Let me give an example of how this can
be really annoying.
Suppose I was given an account at LCS, and I wanted to login there for
the first time using telnet -safe from Athena. Suppose the LCS machine
did not run "telnetd -a off" as the Athena dialups do.
I try "telnet -safe foo.lcs.mit.edu", and get "You are not authorized."
Oh, of course! I'm brlewis@ATHENA.MIT.EDU, not brlewis@LCS.MIT.EDU. No
problem, I'll just use ATHENA.MIT.EDU tickets to authenticate, and even
though I'm not authorized to autologin, I can still use the session key
to get an encrypted session in which I can type the needed password,
right? Wrong. Because my Athena principal isn't authorized to
autologin, I can't use it to create an encrypted session.
Sure, I could kinit to my LCS principal at Athena, but what if the
account at LCS was not kerberized? It seems to me that encryption is
useful enough that you should be able to get it with any old Kerberos
principal, not just one that's authorized.
More succinctly, it's fine to couple encryption and authentication, but
I don't like the current coupling of encryption and authorization.
