[2805] in Kerberos
user2user confuser
daemon@ATHENA.MIT.EDU (Donald T. Davis)
Fri Sep 10 01:42:38 1993
From: "Donald T. Davis" <don@GZA.COM>
Date: Fri, 10 Sep 93 00:45:23 EDT
To: jim@suite.com
Cc: kerberos@MIT.EDU
jim miller asks, "why does the kv5 user2user sample code have the server
initiate the authentication & talk to the kdc, when the davis&swick paper
prescribes that the client would play this role?" (my paraphrase)
i haven't seen the sample code, but the u2u server code doesn't care which of
the application correspondents calls itself a server. that is, neither the kv5
server nor the user2user paper makes this distinction, because both sides
of the application connection have to hold TGTs in order to enter the u2u
protocol. for example, it's possible in principle for an nfs server to get
a tgt of its own, and then to enter the u2u protocol as an authentication
initiator (but in the words of tricky dick, "yeah,... we could do that...
but it would be WRONG!").
certainly, ralph & i explicitly intended that the paper would discuss/embrace
the general case; we explicitly kept x servers and the rdist protocols in
mind throughout our work on the problem. i agree, though, that the sample
code offers a generalization that we hadn't thought of.
since i know the author of the u2u sample code, i suspect that he wrote it
backwards just to see if it could be done, or possibly to show off that it
could. by contrast, i'm told (by ted ts'o) that mit's x-authentication code
will have the x client initiating the authentication & talking to the tgs.
that code is in preparation now.
however, x is other; it is backwards and confusing, and thus it is sometimes
natural for a user to initiate authentication on behalf of his x server.
for example, suppose you want to play a networked game, where users initiate
sessions with a game-server, and where the game-service runs on an insecure ws.
suppose further that the game-server needs to send pixels to the players'
x servers. in that case, the game-client initiates the connection and the
authentication, on behalf of the user and his X server. thus, the sample
code isn't absolutely far-fetched, and though it is confusing, the confusion
is inherent to the fact that the x server is a local animal. nevertheless,
i agree with ted that that the sample code should be replaced/fixed, on the
ground that the sample code needs to illustrate the typical case, and i
think rdist and x-supported messaging are more typical user-to-user scenarios.
-don davis (co-author of u2u)
openvision/geer zolot assoc.
1 main st. cambridge, ma 02142
