[1582] in Kerberos_V5_Development
Re: ftpd should allow protection to be required
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Thu Aug 15 14:07:32 1996
Date: Thu, 15 Aug 1996 14:07:11 -0400
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: brlewis@MIT.EDU
Cc: Sam Hartman <hartmans@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Bruce R. Lewis's message of 15 Aug 1996 10:11:16 -0400,
<nm9viekvit6.fsf@kindness.MIT.EDU>
From: brlewis@MIT.EDU (Bruce R. Lewis)
Date: 15 Aug 1996 10:11:16 -0400
If you want to put an option into telnetd to require that encryption
start before login, you will want to look at the Athena code even if the
behavior you want is slightly different. The trouble is this: If a
telnet client supports encryption and is going to encrypt, it sends
X,Y,Z, ENCRYPT REQUEST-START and ENCRYPT START. If a telnet client
supports encryption but isn't going to encrypt, it sends the same X,Y,Z
and then nothing. You have to do a timeout. I think this is brokenness
on the part of the protocol.
Well, the protocol is designed so that the order in which various telnet
options are negotiated are free-form, and this added flexibility makes
it hard to do barrier syncronization --- which is needed not only for
the encryption option, but also for such telnet options as the telnet
environment option and the terminal-type option, since telnetd has to
wait until they are negotiated before forking off the child.
I've had to implement this in the V5 telnet sources, which I implemented
in conjunction with a new AUTH_HOW bitmask --- ENCRYPT_ON. If the
ENCRYPT_ON on bit is set in the authentication modifier word, then
encryption *must* be negotiated, or the connection will fail. (To
prevent an attacker from simply clearing this bit, the authentication
type pair is checksumed and protected in the Kerberos authenticator.)
This allows the client to negotiate encryption at the very beginning of
the authentication sequence, and it prevents some of the active attacks
than an attacker might use.
My other beef with the protocol is that you can't use kerberos
encryption unless your principal is authorized to login, so you can't
just encrypt with kerberos and type a password to login as somebody
else. This is because the AUTHENTICATION option really means
AUTHENTICATION-AND-AUTHORIZATION, at least in this implementation. I
haven't looked at the protocol closeley enough to know if you could
separate authentication and authorization.
This is more of an implementation issue. Of course, the functionality
that you really want isn't really an AUTHENTICATION option, but rather a
SESSION-KEY-ESTABLISHMENT option for the purposes of making encryption
option.
Using Kerberos V5, there's a much simpler solution to the problem; we
can just forward the V5 credentials to the remote machine as part of the
telnet authentication. That way, you have remote tickets on the server
without requiring the user to type her password over again. In order to
get AFS tokens, we'll have to take the V5 tickets and get them converted
to use V4 tickets, using krb524d, but that's only a little bit extra
work.
I have a UROP student working on doing exactly this for the V5 ftpd, for
the Athena dialup ftp service.
- Ted
