7 Nov
2018
7 Nov
'18
4:24 a.m.
On Tue, Nov 6, 2018 at 1:40 AM Grant Taylor via TUHS <tuhs(a)minnie.tuhs.org>
wrote:
What I meant is that SSH supports a limited sense of checking whether a
given key matches and making a yea or nay decision based on that.
[snip]
Ha! That's a hoot.
[snip]
- Dan C.
On 11/05/2018 03:34 PM, Dan Cross wrote:
[snip]
Isn't that authorization?
Security, in general, usually seeks to address
five questions:
1. Authentication - Is some entity who it claims to be?
2. Authorization - Is some entity allowed to perform some action?
3. Privacy - Can a third party snoop on a private conversation between
two entities?
4. Integrity - Can a third party alter communications between two
entities in an undetectable way?
5. Non-repudiation - Can it be definitively shown that some entity was a
party to some communication?
The 3rd A that I'm used to is "Access Control". Is the requested action
allowed given the above information.
Kerberos is a authentication protocol.
Not really. It provides the data that lets one perform a relatively weak
validation of e.g. a password, but it is not *itself* an authentication
protocol.
LDAP, YP (retroactively named NIS after a lawsuit involving, I believe,
British Telecomm), NIS+, NetInfo, Active Directory, and Hesiod are all
examples of directory services. To a first-order approximation, one
might think of a directory service as providing an oracle allowing one
to discover what entities exist in some domain.
Authentication protocols and directory services solve different
problems. Though in true Micro$oft-of-old fashion, AD sort of merged
both.
I would argue that a directory including shadow information (like
NIS(+)) does both too.
Kerberos solves the authentication problem, but does
not provide a
Older versions of Kerberos often included modified versions of popular
servers and their clients that had been modified to use the kerberos
protocol for authentication, and also often to encrypt communications. For
example, the version of `telnet` that shipped with MIT kerberos back in the
day had an option that could be used to encrypt the data stream; similarly
with rlogin, et al. I have a dim memory that the version of FTP might
support encryption for the control connection but not data connections (but
I also might be purely imagining that). I'm guessing most of this stuff has
been dropped from more recent distributions because...really...telnet?
[snip]
directory service nor does it solve the
authorization problem (though
some "kerberized" services could use a library to consult a
user-provided file of ACLs mapping principals to privileges). On Unix,
"authorization data" includes things like your UID and the set of groups
you belong to (or more precisely, your process's UIDs and GIDs/groups).
Kerberos provided support for privacy via encryption libraries, and it
provided support for integrity via hashing/checksumming/signature
libraries. "Kerberized" versions of network services such as telnet,
FTP, rsh/rlogin/rcp etc all provided support for authentication via the
baseline Kerberos protocol as well as privacy and integrity via
connection-level encryption and checksumming.
I was not aware that Kerberos could provide privacy (encryption) for
kerberized services. I (naively) thought that Kerberos was
authentication that other things could use to make access control
decisions.
In its pure
form, SSH provides support for limited authentication (via
public key cryptography and the wide distribution of public keys) and
limited authorization (via the `authorized_keys` file), privacy and
integrity.
I think that OpenSSH's certificate support extends that a bit.
Even if communications with the NIS server was
encrypted, I'm not
hearing anything that prevents an authenticated user from enumerating
NIS. Even if it was over encrypted channels.
Correct. `ypcat passwd` often gave you a bunch of hashed passwords in field
two of a stream 7th Edition /etc/passwd formatted entries.
I have, again, some vague memory that at some point this was changed so
that root on the localhost could get a shadow-style map, but normal users
couldn't see the password hashes. But I might totally be making that up,
and of course, it wasn't robust security since what went over the wire
wasn't encrypted and breaking root on a host could still get you all the
hashes on the network. Contrast with Kerberos, where breaking root on a
host doesn't compromise much beyond that host (modulo leveraging that to
steal user passwords and the like).
[snip]
Hesiod, which
seems unique to Athena, was kind of neat; it piggy-backed
the need for a directory service on DNS, which is already a distributed
directory service. You embedded relevant data into DNS TXT records, so
imagine doing a DNS query to look up a user's /etc/passwd entry: after
all, DNS already scaled and was well-proven Internet-wide. I don't know
that anyone ever really supported it, though.
I know that Red Hat Linux did have support for it. One of my colleagues
was a Hesiod maintainer for a while.