[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Naming 2: untrustable hosts
The IPv6 specs say that the potential for authentication is mandatory.
The draft API spec (in a concept I didn't challenge...) stated that
both services and systems could impose a mandatory minimum security
level. Presumably, these services or hosts would not talk to a peer if
it could not negotiate a key with that level of security. What happens
with inherently untrustable machines, such as shared PCs in a
university lab? Are these machines to be barred from some class of
Internet services?
One reason for demanding authentication, even at the coarse granularity
of a host, is so that you know who should be held accountable. It
seems, then, that such machines could have a key if the key was bound
to the person using it at the time. In other words, a Kerberos-like
(or more precisely, an Athena-like, since it fits the Athena philosophy
of whom you authenticate) name of ``user@domain'' might be used here,
whereas a timesharing machine or a PC used by just one person would
have a key bound to ``domain'' or maybe ``@domain''. And this in turn
imposes some requirements on the forms of names that the key management
protocol must deal with.
I realize that one objection to this proposal is the notion that that
user-granularity security is (to quote the response to a previous message
of mine) ``an explicit non-goal''. But I don't see any other way to
handle inherently untrustable machines.
--Steve Bellovin
Follow-Ups: