🚀 go-pugleaf

Perhaps there ought to be pairs of keys - one key for
the principal-as-client; the other for principal-as-server.
For example, I could have a key K-steiner-c which corresponds
to my password and which I use to decrypt ticket replies from the
authentication server, and a key K-steiner-s which I use to
decrypt tickets from would-be clients of a service I am providing.
This way, if someone compromises my K-steiner-s key, they can
falsely "authenticate" themselves to me, but they cannot
impersonate me.  The two keys can be protected at different levels of
paranoia accordingly: I don't want to write down my password or
store it on disk, but I do want to be able to remember it.  My
server key, on the other hand, I might be willing to keep in a
file, and I don't care if it's hard to remember (it can just be
a big random number).

Similarly, a server could use one key, K-server-s, to decrypt
and verify tickets from prospective clients, and use another
key, K-server-c, to obtain tickets for other servers from Kerberos.
This might also be useful for peer servers (e.g. two Zephyrs
exchanging data, if they authenticated to each other), because
they could use different keys depending on who was acting as
client (initiator) and who was acting as server (responder).

Jennifer