Kerberos and Public-Key Infrastructure Key Points Kerberos is an authentication service designed for use in a distributed environment. Kerberos makes use of a thrusted third-part authentication service that enables clients and servers to establish authenticated communication. X.509 defines the format for public-key certificates. This format is widely used in a variety of applications. A public key infrastructure (PKI) is defined as the set of hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates based on asymmetric cryptography. PKI implementations typically make use of X.509 certificates. 5 Many-to-Many: Threats User impersonation Malicious user with access to a workstation pretends to be another user from the same workstation Can t trust workstations to verify users identities Network address impersonation Malicious user changes network address of his workstation to impersonate another workstation Eavesdropping, tampering and replay Malicious user eavesdrops on, tampers with or replays other users conversations to gain unauthorized access Goal of Kerberos Trust model Unified user-service authentication Fine, centralized, access controll Interdomain authentication Only authentication Single authentication server All users/workstations/servers trusts the authentication server Authentication server may trust other authentication servers 1
Trust model Advantages Compromise of a host does not directly compromise other hosts Centralized management Disadvantages Makes no sense in isolated systems Hosts still have to be trustworthy... No protection against trojans/viruses/worms Trust model Kerberos design goals No cleartext passwords on the network No client passwords on servers Minimize password exposure on workstation Compromise only impacts one client/server/user Minimize the need for the password (single signon) Kerberos version Parts of a Kerberos system v1-3 are no longer used (and badly broken) v4 is still common (and broken) v5 is most commonly used We start with v4, then we take v5. Authentication Service (AS) Ticket Granting Service (TGS) Key distribution center (KDC) User Service Ticket Granting Ticket (TGT) Ticket Authenticator Kerberos Library Tickets Important fields in ticket Fundamental concept in kerberos Contains information about: Owner Target Session key Lifetime Encrypted with target's key A ticket to Bob is encrypted with a key shared by Bob and the TGS Name/Instance/Realm Timestamp (Unix time) Lifetime (8 byte, 5 min steps, max ca 21 hours) Session key (8 bytes, DES) 2
Authenticator Getting a TGT Proves ownership of a ticket Created by encrypting current time with the session key in the ticket Verified by decryption and comparison of timestamp to current time Prevents replay attacks Requires synchronized time (NTP) Type username, password and realm at workstation Workstation asks AS for TGT for Username AS creates session key, creates TGT, encrypts with master key generated from password KDC sends TGT to workstation Workstation decrypts TGT, gets session key. Get a ticket Use a ticket Workstation sends request, TGT and Authenticator to TGS. TGS decrypts TGT, gets Session key. Uses session key to verify Authenticator TGS generates session key for Bob, creates ticket, encrypts with Bob's master key. TGS sends ticket and session key to bob secured with the session key from the TGT Send request, ticket and authenticator to Bob Bob decrypts the ticket to get the Session key. Bob verifies the Authenticator Bob creates a new authenticator with time+1 and sends back (Why?) Bob allows you to access the service Replicated KDC Realms Limits the impact of KDC downtime Most KDC operations are read only One master copy of the KDC database must exist Replication is part of the kerberos protocol Administrative domains within kerberos Allows trust relationships between different organisations All tickets contain information about the realm of the owner and target. 3
Authentication in a different realm Kerberos V5 Locate the realm of the service Ask the KDC of your own realm for a ticket to the other realm KDC Ask the KDC of the target realm for a ticket Authenticate directly to the service with your ticket. Used in Windows (Active Directory, RFC 3244) Used in many Unix systems Major overhaul of Kerberos v4 ASN.1 Changes to the cryptpgraphy A way to describe data structures Extremely complex Used instead of the simple byte descriptions in Kerberos v4 Where ASN.1 is used, chaos follows Kerberos v5 is described in ASN.1 Support for more ciphers (not only DES) Windows uses RC4 3DES, AES etc. are possible New, homegrown, cipher modes... Allow delegation by proxy Allow delegation by forwarding A special request is done to the KDC for a new ticket Send a network adress instead of the one in the TGT KDC returns a ticket with the proxy adress Send the Ticket to the adress where it is to be used Use it as normally Request a TGT with a new adress Send the TGT to the new adress Use the TGT as usually 4
Renewable tickets Prevent password guessing Short lifetime of tickets in v4 (21 hours...) Long lifetime of tickets is risky Revocation is not practical Allow tickets to be renewed A ticket can be renewed as long as it is valid Each ticket has a last legal time Kerberos v4 makes offline attacks trivial Kerberos v5 sends the current time encrypted with the master key to request a TGT (preauthenticator) Prevents requesting a TGT for somebody else Kerberos v5 has a flag to prevent tickets to be issued for password based users Public Key cryptograpy Weaknesses in Kerberos Not yet a standard Uses RSA to authenticate user and AS Signaling is done using a magic number in the pre-authenticator No changes to the rest of the kerberos protocol Broken cryptography (v4) Homegrown cryptography (v5) Simple offline attacks (v4) Single point of failure (v4, v5) Multiple users on one system (v4,v5) Replay attacks within timescrew (v4) Terminology Public key infrastructure x.509 CA: Certification Authority RA: Registration Authority x.500: Electronic Directory Services x.509: Authentication framework 5
Certificates Trust anchors Uses asymmetric/public key cryptography Binds an Identity to information and key material Has an issuer, a subject and a verifier A public key trusted to sign certificates Implicit trust Basis for any PKI system Might be a part of a certificate (also known as root certificates) Most vulnerable point of any PKI At some point we must decide to trust a key for noncryptographic reasons Trust models Chains of trust Describes how trust is distributed from the trust anchors Describes the relationships between certificates Based on trust anchors Finds a trustworthy public key for an identity Two major paradigms: Chain of trust Web of trust Form a chain of certificates to a trust anchor (Usually) Hierarchical structure Certificates have relationships such as parent, child or sibling Monopoly Monopoly with multiple RA A single CA acting also as RA One key to rule them all... All signing is done with this single key Frequently used for software distribution Can be used inside an administrative domain No certificate chains The single certificate can be embedded in all software that needs it Split up the RA and CA Still just one key Used when an organization does not wish to take the CA responsibility You have to trust both the CA and the RA for the certificate 6
Delegated CAs Oligarchy One trust anchor Signing permission can be delegated Multiple CA/RA CA's might be limited to part of the namespace You have to trust the anchor and all certificates in the chain Most common model (used by browsers) Multiple trust anchors Each trust anchor forms a chain similar to Delegated CA's No single point of failure Multiple catastrophic points of failure Cross-signing Chain of trust summary Web of trust (Anarchy) Efficient Centralized structure Well suited for administrative control Absolute trust Reliance on a limited number of trust anchors Catastrophic failures Used by PGP Your own certificate is your trust anchor Trust from the number of relationships Mimics human relationships/trust Trust score is assigned by trust paths Short paths give higher trust More paths give higher trust Trust score is a sliding scale, not binary. Web of trust Revocation Requires a (non-trusted) database of users Trust is a graph problem Scaling problems Administrative problems No single point of failure No catastrophic failure modes How do I get a secure connection to somebody far away...? What do we do when somebody stole our private key? We revoke it! But how...? 7
Certificate Revocation Lists On-line Revocation Server Each CA regularly generates a list of invalid certificates it has signed. The user downloads the CRL before verifying a certificate from the CA If the Certificate is in the CRL it's invalid CRL can get very large Delta-CRL Full-CRL Does people check CRL? Allow users to check the CRL in real time Uses Online Certificate Status Protocol (OCSP) Adds an on-line part to the PKI OLRS can issue revocation certificates This proves a certificate was valid at a specific time 8