[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bellovin's and Ahar's attacks
My concern with per-user keying has stemmed from my inability
to see how it will work in practice. Let me take more than the
usual space to suggest where I see problems.
Consider the admind daemon that is used in Solaris for system
administration. This is the server that answers admintool
requests. It is used for many purposes, but the one of
interest in this discussion is managing user accounts.
Specifically, you can install new users or modify their
account information, including their passwords. While not true
now, I think we can agree that when modifying a password entry
in a table or database, the hashed passwd should not be
transmitted in the clear.
I may or may not answer in more detail later, and if I do it won't be
till next week; I have some seders to go to. For now, I'll say that
the answer to your question is really a naming issue: how are the
client and server named. My first cut at an answer is that clients
have more or less arbitrary names not tied to an IP address or DNS
host name (except for host-to-host services such as NFS), though the
certificates probably live in the DNS tree via the same administrative
structure. Servers are named by <service,DNS name> pairs -- the client
knows the name of the destination, and wants to assure itself that it's
talking to the right party. In your example, the client would ask
for the certificate for something like kadmind@your.host.name. (No,
I'm not recommending that syntax; I'm just looking for something that
clearly and unambiguously denotes a service on a machine.)