[1000] in Kerberos_V5_Development
X authentication stuff
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Feb 6 23:28:14 1996
To: krbdev@MIT.EDU
Cc: "Ralph R. Swick" <swick@x.org>
Cc: "Donald T. Davis" <don@cam.ov.com>, (Sam Hartman), krbdev@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 06 Feb 1996 23:28:02 -0500
In-Reply-To: "Ralph R. Swick"'s message of Mon, 05 Feb 1996 08:19:17 EST
I wanted to document some potential problems that Tom and I
discovered in the current X authentication implementation , so that we
have no excuse for not fixing them. (Tom is already working on fixing
these, but this is intended as a check list to make sure problems in
the final protocol are resolved.)
As I understand the protocol as it stands, when the Kerberos
authentication type is chosen, the X dispatch table is replaced with a
new table, so that a multi-stage authentication process can take
place. The X server sends a TGT or a principal to authenticate to (if
a srvtab is being used).
At this point, the client currently does no authorization
checking. Both in the u2u and srvtab case, the client really needs to
do authentication checking. Perhaps, reasonable defaults should be
chosen, such as allowing host/hostname and X11/hostname for srvtab
authentication and allowing a tgt belonging to the same principal that
is in the local ccache for u2u.
(It would be nice if the authenticators for the app-req message
included a checksum field, even if a constant string is being
checksummed. This way, the authenticators do not conflict with
authenticators used by appl/bsd/*, even when you are authenticating to
host/hostname. )
The second major problem with the scheme is how you integrate
integrity and encryption. Tom had originally proposed to have an X
extension for encryption, and not to offer integrity. This is
problematic because any system that has a window after authentication
has been performed, but before integrity is enabled is vulnerable to
IP-level attacks. (AKA Telnet) At the very best, you will know if
your connection has been stolen; in my opinion, this is inadequate,
especially when the server continues to let the intruder use the
connection.
Tom was looking at ways to integrate negotiation of integrity
checking with authentication; once you have integrity checking on the
connection, you can enable or disable encryption at the user's
convenience. This may be difficult because we need to work with X to
find a clean approach for integrating this on top of the X protocol.
In my phone conversation with Don, he pointed out that we
didn't have to transmit a checksum with every packet; if we
transmitted a running total checksum every few packets, the window for
damage would be fairly small. (This assumes that the server will only
service a certain number of requests between such integrity packets.)
We could rely on the TCP checksums for data integrity, assuming
anything that spoofed the TCP checksum but not the cryptographic
checksum was an attack.
Just some random comments.
--Sam
