Re: [TUHS] YP / NIS / NIS+ / LDAP

[Dan Cross <crossd@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5251 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 6814 bytes --]