[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 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.
I'd go for untrustable machines be allowed to access only on what name/
IP# it has, and not anything finer than this, unless it had already been
authenticated by a more sophisticated means by the server as having a
user@host attribute. So if that meant it were otherwise barred from
doing rsh, rlogin, rexec, sending mail, I'd accept it and I can't see
why there would be much opposition. I think the problem then would be
ensuring such services enforced the appropriate policy (;) and (maybe)
even demand different levels of authentication depending on "network
location", etc.
If someone is telnetting from a PC in a general access lab, then I'm not
really concerned about if they have a valid login on the PC (if I were
I'd probably want video camera's in the lab along with a way to handle
access to the area). In my experience, it is the nature of students to
share passwords (no matter how much you say "NO, YOU CAN'T DO THAT") and
presumably trhis happens elsewhere too. I might add that this is not
the same as crackers "breaking in". Heck, even if we issued secure-id
cards to students, I'm sure there'd be "can I borrow yours to print this
out, I left mine at home" type of situation. Hmm, I seem to have
wandered a bit here...To sum up my comfort level with PC's and security,
we don't allow PC's using NFS to write to any drives except those with
home accounts which are the nosuid, etc, type, regardless of who is
logged into them.
I like the idea of a system requiring a minimum security level, with
services being able to demand that minimum. If one of the levels happens
to be, or equivalent to, user authentication, then so much the better for
those serives which can _reliably_ provide such. On this, maybe it is
worth mentioning the requirements for each level of authentication, so
that the traditional password sent in clear text over the network isn't
and can't be given the same level of trust as a challenge-response
system and that a "claimed username" not be trusted just because of
some arbitary number in the IP header(s) being right.
darren
References: