On Tue, Nov 6, 2018 at 8:40 AM Grant Taylor via TUHS <tuhs@minnie.tuhs.org> wrote:
On 11/05/2018 03:34 PM, Dan Cross wrote:
> You can use a modified `login` that will validate you against a KDC.

ACK

These days the modification generally consists of pam_krb5 added to the system's PAM configuration.


> Modifications have been made to e.g. SSH so that one can authenticate an
> SSH session via GSSAPI, which usually wraps Kerberos. If I recall,
> GSSAPI might be one of the lasting legacies of the DCE, though I may be
> misremembering history.

*nod*

And similarly – in other protocols (IMAP, SMTP, IRC, the same LDAP) one can authenticate a session via SASL, which usually wraps GSSAPI, which usually wraps Kerberos.

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

You're right, it's primarily an authentication protocol. But due to the way it works, it *also* negotiates a 'session key' between the user and the service, which then may be used for transport encryption (sealing). It's not commonly used as far as I know – most new protocols already have their own security layers such as TLS or SSH.

Actually LDAP is the only still-widespread protocol that comes to mind whose implementations frequently make use of Kerberos-based encryption (via GSSAPI). This is especially common in Active Directory environments, where the DCs might not have a valid TLS certificate.

(I seem to recall kerberized Telnet didn't survive because it was limited to DES/3DES for an odd reason. Didn't quite understand why that was the case, though.)

--
Mantas Mikulėnas