[PPT] - Cross-Realm Kerberos Authentication A study into implementations and PowerPoint Presentation

SLIDE 1

Introduction Background Approach and Results Conclusion

Cross-Realm Kerberos Authentication

A study into implementations and compatibility Esan Wit Mick Pouw

Supervisor: Michiel Leenaars

A System and Network Engineering RP University of Amsterdam

July 3, 2014

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 1 / 19

SLIDE 2

Introduction Background Approach and Results Conclusion

Introduction

Around since ancient times (’80s)
Version 5 from 1993, revised in 2005
Offers authentication in networks between clients and services
Single Sign On
“Yesteryear’s OAuth”
Many implementations exist
Active Directory
Heimdal
MIT Kerberos
Shishi

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 2 / 19

SLIDE 3

Introduction Background Approach and Results Conclusion

Previous research

Implementation of cross-realm referral handling in MIT

Kerberos client

Research by Cervesato et al. illustrated the possibility to

impersonate users by rogue KDCs

Much debate about cross-realm options
But very little in the way of implementations
Specifying Kerberos 5 cross-realm authentication

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 3 / 19

SLIDE 4

Introduction Background Approach and Results Conclusion

Goals

The goal is to check the current status of Kerberos implementations and identifying possibilities for dynamic configuration to enable cross-realm authentication. E.g. using an @OS3.NL account to authenticate a user for their Facebook profile.

Analyse the interoperability between implementations
Research default behaviour for edge cases
Research options for Cross Realm trust configurations
Analyse cryptographic behaviour

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 4 / 19

SLIDE 5

Introduction Background Approach and Results Conclusion

Kerberos recap

Authentication provider relying on trusted third party
Based on shared secrets
Tickets are encrypted so only the intended recipient can

decrypt it

Designed to provide authentication on untrusted networks
Password is not send over the network
Supports public key cryptography

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 5 / 19

SLIDE 6

Introduction Background Approach and Results Conclusion

Kerberos Illustrated

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 6 / 19

SLIDE 7

Introduction Background Approach and Results Conclusion

Kerberos Cross-Realm Illustrated

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 7 / 19

SLIDE 8

Introduction Background Approach and Results Conclusion

Testing basic functionality

Testing combinations of all implementations, focused on

receiving a valid ticket

Clients authenticated using password
Services using keytab via GSS-API

Requirements

Machines taking role of either client, service, or KDC.
Configured DNS
Patience

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 8 / 19

SLIDE 9

Introduction Background Approach and Results Conclusion

Testing basic functionality

Testing combinations of all implementations, focused on

receiving a valid ticket

Clients authenticated using password
Services using keytab via GSS-API

Requirements

Machines taking role of either client, service, or KDC.
Configured DNS
Patience
A lot of it

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 8 / 19

SLIDE 10

Introduction Background Approach and Results Conclusion

Testing basic functionality

KDC Client Active Directory Heimdal MIT Shishi Active Directory ✓ ✗1 ✗1 ✗1 Heimdal ✓ ✓ ✓ ✓ MIT ✓ ✓ ✓ ✓ Shishi ✓ ✓ ✓ ✓ Service Active Directory Heimdal MIT Shishi Active Directory ✓ ✗1 ✗1 ✗1 Heimdal ✓ ✓ ✓ ✓ MIT ✓ ✓ ✓ ✓ Shishi ✗2 ✗2 ✗2 ✗2

Table: Compatibility between implementations

1No service available for testing 2Shishi GSSAPI not implemented yet, but service ticket can be requested Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 9 / 19

SLIDE 11

Introduction Background Approach and Results Conclusion

Crypto compatibility

Active Directory Heimdal MIT Shishi AES128/256-SHA1 ✓ ✓ ✓ ✓ CAMELLIA128/256- CTS-CMAC ✓ DES3-CBC-SHA1 ✓ ✓ ✓ DES-CBC-CRC3 ✓ ✓ ✓ DES-CBC-MD53 ✓ ✓ ✓ DES-CBC-MD43 ✓ ✓ RC4-HMAC-EXP3 ✓ ✓ RC4-HMAC ✓ ✓ ✓ ✓

Table: Ciphers implemented

3Considered weak[2] Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 10 / 19

SLIDE 12

Introduction Background Approach and Results Conclusion

Testing PKINIT compliance

Use of public key cryptography for authentication and

encryption

Chain of trust maintained as standard X.509 certificates
Any certificate authority
Extended Key Usage (EKU)
X.509 Subject Alternative Name (SAN) extension
Or if you’re Microsoft:
dNSName containing a SAN of the hostname of the KDC

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 11 / 19

SLIDE 13

Introduction Background Approach and Results Conclusion

PKINIT Results

Shishi no support.
Windows has it’s own format
MIT EKU tested/confirmed
Heimdal support for both formats, EKU tested/confirmed
Connecting to MIT KDC weak encryption, DH parameters

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 12 / 19

SLIDE 14

Introduction Background Approach and Results Conclusion

DNS

Kerberos uses DNS to find the KDC servers of a realm. This is accomplished by using SRV records and will make the realm configuration in the configuration

kerberos. tcp.ad.os3.nl. IN SRV 01 00 88 ad.os3.nl.
kerberos. udp.ad.os3.nl. IN SRV 01 00 88 ad.os3.nl.
Behaviour was analysed under several configurations
MIT Kerberos 5, Heimdal and Shishi clients all use DNS if

realm is unknown4

4provided a user specifies a realm when attempting to perform initial

authentication

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 13 / 19

SLIDE 15

Introduction Background Approach and Results Conclusion

Cross-Realm setup

All manually configured, no automatic options available
Requires shared secret between KDCs
All cross-realm trusts are one-way
Add a principal in the right direction
Two-way trust is possible
Add principals for both directions

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 14 / 19

SLIDE 16

Introduction Background Approach and Results Conclusion

Cross-Realm requirements

Active Directory Heimdal MIT Shishi Active Directory ✓ ✓ ✓ ✗5 Heimdal ✓ ✓ ✓ ✗5 MIT ✓ ✓ ✓ ✗5 Shishi ✗5 ✗5 ✗5 ✗5

Table: Cross compatibility

5Shishi does not support cross realm configuration Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 15 / 19

SLIDE 17

Introduction Background Approach and Results Conclusion

Conclusion

The implementations adhere to the protocol
Most conflicts occur from other variables
Much remains to be done to enable auto-configuration
Public key cryptography for communication between KDCs
Heimdal and MIT Kerberos 5 are most compatible

Note: Many documents are outdated when it concerns Kerberos

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 16 / 19

SLIDE 18

Introduction Background Approach and Results Conclusion

Future Work

Finish Shishi
Better debugging options in the implementations
Improve interoperability between implementations
Dynamic configurable trust
Foreign trust policies
Asynchronous Cryptography for Cross-Realm trust
PKCROSS started as draft but remains unfinished
As of this week some activity again on the mailing list

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 17 / 19

SLIDE 19

Introduction Background Approach and Results Conclusion

Questions?

Takeaways in Kerberos

Check your time
KERBEROS LOVES CAPS (and so do config files)
When in doubt, DNS!

Special thanks to Michiel Leenaars and Rick van Rein for their input and feedback during this project.

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 18 / 19

SLIDE 20

Introduction Background Approach and Results Conclusion

I. Cervesato et al. “Specifying Kerberos 5 Cross-realm

Authentication”. In: Proceedings of the 2005 Workshop on Issues in the Theory of Security. WITS ’05. Long Beach, California, 2005, pp. 12–26. isbn: 1-58113-980-2.

L. Hornquist Astrand and T. Yu. Deprecate DES,

RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos. RFC 6649 (Best Current Practice). Internet Engineering Task Force, July 2012.

Esan Wit, Mick Pouw Cross-Realm Kerberos Authentication July 3, 2014 19 / 19