On Tue, Nov 6, 2018 at 1:40 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
On 11/05/2018 03:34 PM, Dan Cross wrote:
[snip]
> 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.

Isn't that authorization?

> Kerberos is a 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.

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.

> Kerberos solves the authentication problem, but does not provide a
> 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.

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]
> 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.

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]
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.

Ha! That's a hoot.

[snip]

        - Dan C.