kerberos: 30 years later

(A modern cryptographic overview)

Robbie Harwood

Kerberos Development Lead, Red Hat2019-12-05

KERBEROS: 30 years later

WHAT IS KERBEROS?

3

What is Kerberos?"Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology."

-- https://web.mit.edu/kerberos

https://web.mit.edu/kerberos

4


Widely used Anywhere there’s a many/many problem Supported by most applications

This quote is familiar...

6

Kerberos

HeraklesEurystheus

7

Trent

AliceEve

8

Trent

AliceEve

Argos

Bob

python

9


For securing network communication Safe + secure on public networks

On any network

10


Binds actors to names … cryptographically

Secures communication between actors Mutually-authenticated Lays groundwork for authorization Multifactor support

11


Needham-Schroeder protocol (symmetric) Most operations are AES

Very fast Initial step uses elliptic cryptography

Built-in, automatic revocation checking

12


Initiator / Acceptor Doesn’t require machine separation

… can even authenticate an actor to themself Beyond usual notion of “server” “Enterprise”

13


“MIT licensed” (surprise) Installs on your machine

Yes, even Windows The Crypto Wars are basically over

14


Several other implementations availble Heimdal (Sweden) Microsoft Active Directory (AD); proprietary Apple; proprietary Shishi; abandoned and poorly licensed

Implementations interoperate … but I’m doing a MIT-specific presentation

TOPOLOGY

16

Topology

User

17

Topology

User program

18

Topology

User program

Service

19

Topology

User program

Service

?

20

Topology

User program

Service

KDC

21

Topology

User program

Service

KDC

?

Initial credential acquisition

23

Initial credentials (simplified)

User

Service

KDC

AS_REQ (user, crypto)

AS_REP (TGT, encrypted)

24

Initial credentials (simplified)

Service

KDC

Inputs: secretReceives: TGT

User

AS_REP (TGT, encrypted)

AS_REQ (user, crypto)

25

Initial credentials KDC “Authentication Service” (AS) Secret credentials never cross the network Different configurations may require more messages

Multifactor PKINIT Older mechanisms

TCP or UDP, port 88 … or TCP port 443

26

Initial credentials SPAKE (Secure Password-Authenticated Key Exchange)

“Future work” two years ago Elliptic curve-based approach

Prevents offline dictionary attacks … even with weak passwords

Current future work SPAKE’s multifactor interface is extensible TOTP/HOTP (already supported in krb5 differently) FIDO/U2F devices (e.g., yubikeys)

27

Initial credentials

User program

Service

KDC

?Has: TGT

Service ticket acquisition

29

Service tickets

User program

Service

KDC

Has: TGT

TGS_REQ (user for service)

TGS_REP (encrypted service ticket)

30

Service tickets

User program

Service

KDC

Has: TGTHas: service ticket

TGS_REQ (user for service)

TGS_REP (encrypted service ticket)

31

Service tickets KDC Ticket Granting Service (TGS) Communication secured by TGT

(initial credentials) Credentials shared session-wide by default

Credential cache (ccache) Protected from other users May be scoped differently (e.g., process)

32

Service tickets Inside a service ticket:

Lots of timestamps Some names The session key The session key, encrypted for the service

Encrypted with long-term key for target service This principal generalizes Recall that long-term keys never cross the network This determines error messages

33

Service tickets

User program

Service

KDC


?

Authentication

35

Authentication

User program

Service

KDC


AP_REQ (encrypted session key)

AP_REP

36

Authentication

User program

Service

KDC


AP_REQ (encrypted session key)

AP_REP

Acquire credentials (if needed)

37

Authentication Client/server exchange (AP) Not actually a protocol

Means it tunnels along whatever existing channel is in use Client initiator, server acceptor

38

Authentication Service likely unattended

Long-term credentials stored in a keytab Keytab begets ccache

Service doesn’t need to see the KDC Revocation checking happened

USING KERBEROS

40

Using Kerberos Native: libgssapi (C)

Standardized, approachable interface libkrb5: not standardized, harder to use

Also supported through SASL Supported mechanism in SSH Other languages have bindings Python: python-gssapi

Not biased at all, no...

Using (python-gssapi)rharwood@seton:~$ gssapi-console.py

GSSAPI Interactive console

Python 3.7.4+ (default, Sep 4 2019, 08:03:05)

[GCC 9.2.1 20190827] on linux

Type "help", "copyright", "credits" or "license" for more information about Python.

Functions for controlling the realm are available in `REALM`.

Session: /tmp/tmpeVQgJ5-krbtest

Mechansim: krb5 (MIT Kerberos 5), Realm: KRBTEST.COM, User: [email protected], Host: host/[email protected]

>>>

>>> server_name = gssapi.Name("host/seton.mivehind.net")

>>>

Using (python-gssapi)


>>> client_context = gssapi.SecurityContext(usage="initiate", name=server_name)

>>> server_context = gssapi.SecurityContext(usage="accept")

>>>





>>> token = client_context.step()

>>>






>>> token = server_context.step(token)

>>> token = client_context.step(token)

>>>






>>> token = server_context.step(token)

>>> token = client_context.step(token)

>>> token

>>> client_context.complete

True

>>> server_context.complete

True

>>>


>>> message = "I'm the best possible message!"

>>>



>>> encrypted_message = client_context.encrypt(message)

>>>




>>> encrypted_message

"\x05\x04\x06\xff\x00\x00\x00\x00\x00\x00\x00\x004\xba\x00(@\xf2\x0cS\xd2M\x88\x945/$m\xd2\xb0Uol:p\x98\xca\xddw\xda\xeab\xbd\xd1~\xd5Kjo\x15\xad\x08V\xa4\xd4\xa2>\xad\x89\xe2\xb4\x06\x8f\xca\xf1\xd9\xbb\x0e\xf2\x8f\x1a\x06\x86\x9b\x9dx'\xdfT3V\xb0\x17$7\x13\xe1\xfe\x10u"

>>>




>>> encrypted_message

"\x05\x04\x06\xff\x00\x00\x00\x00\x00\x00\x00\x004\xba\x00(@\xf2\x0cS\xd2M\x88\x945/$m\xd2\xb0Uol:p\x98\xca\xddw\xda\xeab\xbd\xd1~\xd5Kjo\x15\xad\x08V\xa4\xd4\xa2>\xad\x89\xe2\xb4\x06\x8f\xca\xf1\xd9\xbb\x0e\xf2\x8f\x1a\x06\x86\x9b\x9dx'\xdfT3V\xb0\x17$7\x13\xe1\xfe\x10u"

>>> server_context.decrypt(encrypted_message)

"I'm the best possible message!"

>>>


DEPLOYMENT

52

Deployment Possible to deploy “by hand”

Not all that difficult Good for testing Additional features require configuration Lots of steps

53

Deployment Red Hat Identity Management

Upstream: freeIPA: https://freeipa.org Packaged in Fedora, CentOS, RHEL

Client packaged in all major distros

Turnkey solution Also sets up CA / PKI, LDAP, etc. Featureset is akin to MS AD

https://freeipa.org/

MULTI REALM

Multi-realm (example)rharwood@seton:~$ kinit [email protected]

Password for [email protected]:

rharwood@seton:~$ kinit [email protected]


rharwood@seton:~$





rharwood@seton:~$ koji hello

안녕하세요 , rharwood!

You are using the hub at https://koji.fedoraproject.org/kojihub

Authenticated via GSSAPI

rharwood@seton:~$

Multi-realm (example)





rharwood@seton:~$ koji hello

안녕하세요 , rharwood!

You are using the hub at https://koji.fedoraproject.org/kojihub

Authenticated via GSSAPI

rharwood@seton:~$ klist

Ticket cache: KEYRING:persistent:21259:krb_ccache_aLv5gM5

Default principal: [email protected]

Valid starting Expires Service principal

10/04/19 14:59:32 10/05/19 00:59:32 krbtgt/[email protected]

rharwood@seton:~$


rharwood@seton:~$ klist -A

Ticket cache: KEYRING:persistent:21259:krb_ccache_aLv5gM5




Ticket cache: KEYRING:persistent:21259:krb_ccache_eeQRbHv



10/04/19 14:59:45 10/05/19 14:59:17 HTTP/[email protected]

renew until 10/11/19 14:59:17


renew until 10/11/19 14:59:17


TIME CHECK

Cross-realm (example)rharwood@conch:~$ aklog athena.mit.edu

rharwood@conch:~$

rharwood@conch:~$ aklog athena.mit.edu

rharwood@conch:~$ klist | grep -i mit

Oct 3 23:56:16 2019 Oct 4 09:55:23 2019 krbtgt/[email protected]

Oct 3 23:56:16 2019 Oct 4 09:55:23 2019 afs/[email protected]


rharwood@conch:~$

Cross-realm (example)

rharwood@conch:~$ aklog athena.mit.edu

rharwood@conch:~$ klist | grep -i mit

Oct 3 23:56:16 2019 Oct 4 09:55:23 2019 krbtgt/[email protected]



rharwood@conch:~$ tokens

Tokens held by the Cache Manager:

Tokens for [email protected] [Expires Oct 4 09:55]

User's (AFS ID 1812) tokens for [email protected] [Expires Oct 4 09:55]

--End of list--

rharwood@conch:~$


rharwood@conch:~$ aklog sipb.mit.edu

rharwood@conch:~$



rharwood@conch:~$ klist | grep -i sipb



rharwood@conch:~$



rharwood@conch:~$ klist | grep -i sipb



rharwood@conch:~$ tokens

Tokens held by the Cache Manager:



User's (AFS ID 1812) tokens for [email protected] [Expires Oct 4 09:55]

--End of list--

rharwood@conch:~$


Questions?

[email protected]:

● MIT krb5: https://web.mit.edu/kerberos● MIT krb5: https://github.com/krb5/krb5

● python-gssapi: https://github.com/pythongssapi/python-gssapi● gssapi-console: https://github.com/pythongssapi/gssapi-console

● freeIPA: https://freeipa.org● freeIPA: https://github.com/freeipa/freeipa

https://mivehind.netGitHub: frozencemetery

This is the backup slide

kerberos: 30 years later

Documents