Lecture 8 Flashcards
What are the goals of Kerberos?
Kerberos aims to provide a consistent way to authenticate to different services, and provide single sign-on across them. It also aimed to facilitate mutually secure interactions between clients and servers and operates securely over untrusted networks.
What are the main difficulties with Kerberos?
Kerberos uses tickets, these contain timestamps, requiring synchronised clocks.
Kerberos contains a single point of failure in it’s distributed system, this is the Key distribution centre, it can be clustered but clients have to be able to reach it, and any user breaking into the key distribution centre breaks all security. Many things are done to prevent this, such as limiting ports, and examining KDC usage.
Keys also could be tied to host names, which is less useful today, when users could come from different devices.
How does Kerberos use cryptography?
Uses Symmetric key cryptography or asymmetric key cryptography, Kerberos uses many pairs of shared secrets, and provides authentication via tickets, this means that you can show what A says about you to B, without needing direct communication between A and B. This is done by including digital authenticated declarations in the tickets.
What are the main parts of the Kerberos architecture?
The parts used in authentication are the client, the software the user controls, and the authentication server, a part of the key distribution centre.
For service authorisation (the main purpose of Kerberos), the parts used are the ticket granting service(another part of the key distribution center) and the Service server, which is the target system users will enact privileges on. Note that there can be multiple clients and service servers.
What are the steps involved with using the Kerberos service?
- User proves identity to their console.
- Their client contacts the authentication service, authentication is then completed and a ticket granting ticket is provided by the authentication service.
- The Client requests service authorisation from the Ticket Granting Service and receives a service ticket.
- The Client contacts the service server, providing the received service ticket and is authorised to access the service.
When does the user prove their identity, and why does this not need to be redone(single sign on)?
The user proves their identity to the authentication server through long term secure credentials, they receive the ticket granting ticket, which allows them to make authenticated requests without requiring the long-term secure credentials again.
Does the Ticket granting service share a secret with anything?
yes, the target service, this allows the ticket granting service to tunnel messages to services via users.
What occurs in the interaction between the client and the authentication server in Kerberos?
The client requests services for the user without sending credentials, the authentication server then checks to see if this is a valid user and if so sends back two messages:
M1: contains the session key between the client and the ticket granting service, is encrypted with the user’s password for the client software.
M2: The ticket granting ticket, encrypted with the key shared by the authentication server and ticket granting service. This contains the client ID, ticket validity, and the session key contained in M1.
The client then decrypts M1 and is now able to authenticate to the Ticket Granting Service with the session key.
What occurs in the interaction between the client and the Ticket Granting Service in Kerberos?
To use a service, a client sends 2 messages to the Ticket Granting Service:
M3: Contains the ticket granting ticket and a service ID.
M4: Contains the clientID, and a timestamp, in encrypted with the session key between the client and ticket granting service. This is known as the “authenticator”.
The ticket granting service decryptes the ticket granting ticket to get the session key and then decrypts the authenticator.
It then sends 2 messages back:
M5: The ClientToServerTicket, containing the client ID, validity, and the session key between the client and service server, it is encrypted with the ticket granting service’s key for the service server.
M6: contains the session key between the client and service server, encrypted with the session key between the client and the ticket granting service.
What occurs in the interaction between the client and the Service Server in Kerberos?
The client sends two messages:
M7: Containing the ClientToServerTicket.
M8: Containing the clientID, and a timestamp, and encrypted with the client to server session key.
The Service Server decrypts M7 to get the client to server session key, it then decrypts M8, an authenticator.
It then sends a message back:
M9: Containing the timestamp from M8+1, encrypted with the client to server session key.
If the client sees everything is all good with the timestamp then the client and server can trust each other and the client can issue requests.
What is Microsoft Active Directory?
Microsoft Active directory combines LDAP, Kerberos, and dynamic DNS, it is used to facilitate almost entirely point and click setup of complex distributed infrastructure.
This Lightweight Directory Access Protocol (LDAP), manages hierarchical directory of principals (users) and group privileges.
Dynamic DNS allows clients to join domains from non-fixed infrastructure.
How can Cross-realm authentication be done with Kerberos?
Take two realms, B.REALM.ORG and A.REALM.ORG, if we want service tickets in B.REALM.ORG to be issued for principles from A.REALM.ORG we just add a special principal krbtgt/B.REALM.ORG@A.REALM.ORG to both realms, these will have the same key and encryption type. For two way trust add the reverse as well.
Why did Cross-realm authentication kill Kerberos 4?
Attackers that control one realm could fabricate principal names to align block-cipher blocks and have target realms help create forged tickets, allowing the attacket to authenticate as the target’s local users.
