[2803] in Kerberos
Re: user-to-user protocol
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Sep 9 16:38:30 1993
Date: Thu, 9 Sep 93 16:17:44 EDT
From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
To: Jim_Miller@suite.com
Cc: kerberos@MIT.EDU
In-Reply-To: Jim Miller's message of Mon, 6 Sep 93 17:36:44 -0500,
From: jim@bilbo.suite.com (Jim Miller)
Date: Mon, 6 Sep 93 17:36:44 -0500
I'm looking at the user-to-user example code that comes with Kerberos
V5 beta 2 and I'm comparing it to the user-to-user protocol described
in the document "Workstation Services and Kerberos Authentication at
Project Athena" by Don Davis(MIT Staff) and Ralph Swick(DEC) dated
March 17, 1989 (user2user.ps.Z).
The user2user protocol used in the Kerberos V5 example is not the
same as the protocol described in the user2user.ps document. The
primary difference is that, in the Kerberos V5 example, the "server"
communicates with the KDC, whereas in the user2user document, the
"client" communicates with the KDC.
Why the difference?
The difference is because the code is wrong. :-) Or rather, while it
works, it really isn't "right".
More specifically, the person who originally wrote the user-to-user
example code wasn't aware of how user-to-user authentication really
ought to work, and he implemented it backwards. That is, the client
code really ought to be the server code, and vice versa.
Your hypothesis that the Kerberos V5 routines are actually more general
than those proposed in the document is partially correct; it is always
the case that who takes on the role of the "Kerberos client" --- by
which I mean who calls mk_krb_req --- and who takes on the role of the
"Kerberos server" --- by which I mean who calls rd_krb_req --- is
dependent of who initiates the TCP connection. This is true both of
user-to-user authentication, as well as normal kerberos connection.
However, it is traditional that entity which initiates a TCP connection
is generally the "Kerberos client", simply because in most cases it is
more important that entity who initiates a TCP connection authenticate
itself to the responding entity, than vice versa. To use a a
non-computer related example, if a soldier is approaching a check point,
it is the guard on duty who says "Halt! Who goes there?" and not other
way around.
The other reason is that traditionally the entity which is initiating
the TCP connection uses mk_krb_req is because it is is usually
representing a human being who is sitting in front of the "client". For
a number of reasons, you don't want to have the user's long-term key
(i.e., password) available on the client workstation, and that is a
requirement for rd_krb_req to work.
User-to-user authentication removes the 2nd restriction, since the whole
point of user to user authentication is so that you can use a
ticket-granting-ticket (which is generally available on a client
workstation) as an authentication target, instead of a fixed service
principal. And, if you are using mutual authentication, the 1st
restriction is lifted, since you do end up authenticating in both
directions.
So for these reasons, the example code in the Kerberos V5 beta 2
distribution is "correct" in that it is secure and it does actually
work. However, it is still done backwards, and is likely to confuse
people --- as Jim demonstrated. For this reason alone, it should be
fixed, and I will do that.
- Ted
