CS 739 Reviews - Fall 2014

Summary:
Kerberos is an authentication service which can be made (almost entirely) transparent to normal users, is simple to administer, and can be utilized by any network application which desires authentication of named users and possibly private communications with those users.

Problem:
- Authentication of users making requests from hosts not under organizational control. (In this case, services cannot implicitly trust the client host’s word on the identity of the user.)
- User must be able to prove identity to each service requested.
- Servers should also be able to prove their identity to clients/users.

Contributions:
- Simple administration. Add user and server names to Kerberos database. Set up master-slave relationships. Maybe provision backups.
- Authentication —> Ticket-granting service: allows user to enter password once to decrypt a ticket allowing future tickets to be requested by client-side calls to Kerberos libraries. This delivers most of the transparency desired, as the user need not be aware of which future tickets he or she is acquiring. Transparency is only lost when the main ticket expires and a password must be re-entered.
- Low additional message cost to use services in a more secure manner.
- A single source of authentication for any number of services in an organization.

Learned:
Kerberos is actually awesome. Very well designed for users, admins, and application authors. A single organization can utilize a similar third party authentication service to reduce cost of managing authentication complexity throughout their many services. Tickets were key to the system.

Confused/Concerned:
- (As a crypto-illiterate, I may be mistaken). Is a password safe enough to be used for encryption? If the private key is deterministically generated from the password, then it can’t have that much entropy. Even though only the initial TGS ticket is encrypted using this key, this will probably happen at least once daily. If the user doesn’t change their password often, a number of cipher texts may be available all encrypted using the same weak secret.

Summary:

This paper provides an overview of the Kerberos authentication model as implemented from the MIT's project Athena. Kerberos is a third party authentication service where the network services and clients that want to use it must register to Kerberos and both the clients and services trust its party's identity given by Kerberos. The protocols used by clients, servers and Kerberos to achieve authentication is described in this paper.

Problem:

In an open network computing environment, a workstation cannot be trusted to identity its users correctly to network services. Therefore there is a requirement for secure, reliable, transparent and scalable third party authentication mechanism which can be trusted by the clients and services to identify and trust other clients and services.

Contributions:

• Introduction of a third party trusted authentication service that is secure, reliable, transparent and scalable.
• Three different levels of protections are provided: (1) authentication only at connection establishment. Further messages are believed to come from the authenticated party if ip-addr is correct. (2) Safe message - authentication for every message but not secrecy or integrity. (3) Private messages - every message is encrypted and authenticated.
• Use of Kerberos Names: Servers and Clients are named same way in Kerberos - primary-name.instance@realm (where primary-name is the name of the user or service ie root, ftp, http etc; instance is the name of a specific instance ie ftp.saikat and realm is the domain name)
• The use of Tickets and Authenticator
• Cross-realm authentication

Learned:

I liked the implementation of Kerberos as a trusted third-party mechanism as an authentication service.

Confusion:

I was wondering what are the implication on how long a tickets should be trusted.

summary:
- they are introducing a third party authentication service for a network system.

problem:
- they have an open network system with different clients and servers and users.
- they need a system to authenticate if the incoming request is from the correct client or the respond is coming from the correct server.

contributions:
- they use private keys (for clients and servers, and temporary session keys), tickets and authenticators to authenticate communications.
- when a user first log in he receives a ticket for the ticket granting server, and it will be used to communicate with TGS and receive new tickets for other services.
- the ticket is encrypted using the user's private key, and can be retrieved if the user provides the correct password.
- the process is transparent to the user. the user only needs to provide his password once and don't need to know about all the tickets for all the services that he uses.
- they use synchronized clocks in their machines (with possibly few minutes difference) and they use time stamps for messages, and if a message is too much in the past or future they reject it.
- they also keep track of the messages that they receive and if they receive an identical message to something that they have seen before they will discard it.
- after a server authenticated the client, they can send an encrypted message back so that client can authenticate the server.

learned:
- I'm not familiar with the authentication systems and the methods that they use, so the way that they were using private keys was new to me. for example in the first step when the user log in: the server creates a ticket, encrypt it using tgs's key, and then encrypt the whole thing using user's key; the user can open the message, but can't read the ticket; and then he can send the encrypted ticket to the tgs and that server can open the ticket and authenticate the client. the flow of information was very interesting.

didn't understand:
- there is a 1 hour period before the slave machines synchronize with master data base. what will happen if a user with new password tries to authenticate using a slave db? would they retry using the master? how can they differentiate between wrong password and out-dated slave?

Summary:
- The paper presents a trusted third-party authentication service to verify users’ identities for client-server transactions.

Problem:
- The paper wants a secure, reliable, transparent, and scalable authentication service for client-server transactions.

Contributions:
- The Kerberos protocol is safe. First, the user/client sends its password to Kerberos for authentication instead of the server, so untrusted servers cannot hijack the password. Second, Kerberos gives the client the ticket for ticket-granting-service, which authenticates the client. The client could verify the server by requesting to server to add 1 to the clients timestamp. This proves that the server knows the session key provided by Kerberos. Therefore, the Kerberos protocol could be used to verify all parties involved, which allows safe forms of communication such as bank transactions.
- Time stamping messages helps prevents replay attacks. Kerberos will realize when multiple clients are requesting tickets and will not respond to requests that do not match the time stamps. This helps prevent the man in the middle attack from sniffing network packets.
- Kerberos is secure because it is built on top of an independent encryption library (DES). Therefore, if anybody finds a more secure encryption library, then the modules could easily be changed to improve security and prevent future attacks.
- Kerberos replicates slave copies every hour for reliability and scalability. This allows many clients to request TGS tickets.

Confusing:
- How does the ticket-granting service work? Is it an extension of Kerberos that knows the tickets of all servers? Or is it an extension of the server that knows how to handle TGS tickets from Kerberos?

Learned:
- Adding a secure third party authentication service can actually help improve the authentication process. One would normally think that adding more parties decreases the security.

Summary
The paper describes Kerberos , a third party authentication protocol between clients and hosts in an open network computing environment .

Problem
There is a need for users logging in as well as for the hosts they interact with to prove each other's identity . Simply sending a password might lead to the user's information being compromised by anyone intercepting messages in the network .

Contributions
Ticket Granting Server - Authenticates a user only once in the beginning and generates the token ( which includes the session key ) which is needed for authentication with servers running the service

Use of session keys for authentication between client-server and vice versa during the period the user logs in and uses the services in the given network

Keeps track of past requests with valid timestamps to prevent replay attacks .

Increased availability by replicating the Kerberos database and using the slave machine in case the master goes down

Introduced the notion of realms which supported Kerberos running in separate administrative domains allowing users to access remote services

Comments
Its interesting to know how Kerberos transparently decoupled user's authentication with that of the client and server interaction.

However , how does Kerberos deal with failure of the Kerberos server and with clock syncrhonization issues with all the nodes in the system ?

Summary: This paper describes Kerberos, a distributed authentication service for a network of computers with untrusted clients.

Problem: In a networked environment, where not all machines are under complete organizational control, authentication of users should still be possible. In addition, authentication should be transparent to the end user. In addition, the system should be secure from snooping, and, just like traditional distributed systems, must be reliable.

Contributions: Kerberos provides a scalable solution to the problem described above. Essentially, they describe a Security Service, which any application can use to give access to trusted users, and ensure that the users are who they say they are. There are several important features:

1. Tickets - To get access to a server, one must get a ticket. Tickets are granted through a Ticket Granting Server, which is itself access through Kerberos (which requires a password). With a ticket, one can access some specific server for some length of time.

2. Session Keys - To guarantee that the users are who they say they are, Kerberos signs information with a session key based on their password.

3. Replication - Because authentication is essentially a database of users and their passwords, the database can be replicated to allow for higher availability and lower latency when used.

Not Understand: How does the server generate the session key, specifically? That is, it seems insecure to simply store the password in the database to generate the session key, since it could be compromised.

Learned: Nothing particularly special here. It uses many standard techniques we've seen before.

Flaw: Decryption of message done by client. That is, Kerberos encrypts the initial packet with a key based on the password. The client then creates the key from the users password, and tries to decrypt the packet. Since this is done on the client end, any user could spoof another users username, and then (like a hash) try to decrypt the message until they get the password right.

Summary:
The authors described about Kerberos, a trusted third party authentication service for open network computing system. Later this system with cryptographic primitive upgrade is accepted as Kerberos protocol for network authentication.

Problem
In a open network system there are multiple point of compromise, and all component must be secured to provide complete security. For example, the server, the client should be able to prove each others identity. The communication amongst server and client should be secured. To prove identity the client need to get access from an access control server which has to be secured. The moment there are multiple components in a system and building distributed trust among them is very difficult. Security of the whole system is minimum of the individual components.

Contributions

• The authors first time proposed about the notion of third party authentication in a distributed system as well they shown a fully functional model and implementation of it.
• The concept of Ticket Granting server like renewing trust within a lifetime. This also take away lot of load from Kerberos itself.
• Their service is agnostic to underlying encryption or key management procedure. As we know every encryption primitive is bound to die over time, Kerberos can easily be upgraded with newer more secure primitives.

Confusing
They told they assumed the server and client clocks are synchronised up to several minutes. What happens in presence of malicious client, can they game the ‘lifetime’ parameter?

Learning
The authentication and renewing trust within a limit is a bound trade off between security and usability. The lifetime of session, is good parameter to tweak based on the threat model one wants to address.

Summary
The authors describe Kerberos, a third party authentication service.

Problem
Time sharing networks require users to gain access. Passwords based mechanisms are very common. Sending passwords across the network would risk the password being sniffed. In addition to that networks are dynamic, so need a security system that can scale.

Hence, the authors try to come up with a system that is reliable ,secure and scalable.

Contributions
Modular design helps system to change authentication schemes at will.
Administration and usage is decoupled. This is done by providing seperate read-write and read-only servers. This simplifies scalability.
Three level authentication scheme is used. This provides users flexibility to decide on the level of security they need.
Tickets are used as proof of identity. This prevents re-authentication for specific time (age of the ticket).
Use nonce messages to protect the system from the replay attacks.
Cross realm authentication to used to provide trust domains.
Use of authentication to prevent sniffing.
Reliability is provided by master slave model.

Learned
Modular design grants flexibility.
Decoupling correct workloads, improve scalability.
Public/private keys provide a way for secure communication.

Confusing
It is rather unclear how time is synchronized in system. They use nonce to prevent replay attacks. Nonce is based on the assumption that time is synchronized. Still they havent mentioned anywhere how they are synchronizing the time.

Summary,
In this paper the authors discuss Kerberos a third party authentication service that can be used to safely identify users and clients to a set of services running over an untrusted network.

Problem,
In an untrusted network where the identity of any system can be compromised by malicious users, Kerberos is aimed at providing a safe authentication service that can identify the users and the set of servers providing services to one another. Apart from authenticating the users and the servers the service also enbles the exchange of safe and private messages between the clients and the servers.

Contributions,
Modular design of the authentication service, where the encryption or the database library could be replaced with other libraries based on requirements.
Use of temporary private keys, called the sessions keys which are given to two clients, used to encrypt the messages between the two parties.
Ability to detect replay attacks by adversaries through the use of timestamps.

Learned,
The technique for authenticating the user by using the user's password to generate the encryption key. This way, the user's password is never sent over the wire, once the user enter the password locally, it is used the decrypt the message from the authentication server, the success of which would identify the user correctly.

Confused,
As mentioned in the paper, how is it possible to impersonate a user by tampering the local software of the workstation?

Summary:
The paper discusses details about Implementation and working of Kerberos, an authentication model for open network systems.

Problem to solve:
Provision of an authentication service in an open network which prohibits malicious components from stealing important information form the system. The service has to be reliable as access to all services will depend on the authentication service. The user must not know the internal structure and working of the service provided by Kerberos. Also the service should scale i.e. the software must not break with any changes made to the system accessing the authentication service.

Contributions:
Provision of three different levels of protection based on the requirement of the application run by the user.

Encryption based on Data Encryption Standard used. Being an independent module allows for different implementation to be used. Separation of sensitive and non-sensitive data about the user, providing for better security.

Read only copies of the master Kerberos database allows for better availability and performance.

Use of tickets and authenticators as encrypted messages to authenticate the principal to the server and to validate itself. A provision to validate the server to the client after requesting service is also present.

Replication of database to slave copies by the hour after running a check sum to check authenticity of both master and slave.

Confusing about the paper:
On replication of master the entire data is sent and at every hour. Will this scale? Also isn't there a window where inconsistent results can be in the slave copy? So does it also consult the master on inconsistent read?
Didn't understand what an end server is?
Has current Kerberos module tackled the issues mentioned in the section 8?

Learnings:
Use of a standalone 3rd party authentication provides better security, whose modular design helps maintain and replace functionality more easily.

Summary:
The paper talks about Kerberos, a third party network authentication protocol. It is designed to provide authentication in client-server applications using private key encryption. It maintains its own database of users and passwords and transparently authenticates users to avoid entering password again and again. It prevents replay attacks by maintaining timestamps.

Problem:
- Timesharing systems need to identify each user when he/she logs in for read/write/modify access.
- In an open networked computing environment, user must prove his/her identity for desired service and server must prove its identity. Users and servers do not trust each other. Hence, a third party authentication system is required to provide such services. The identification mechanism should be secure, reliable, flexible, scalable and transparent to users.

Contributions:
1. Kerberos has been introduced as a third party authentication system which is secure, reliable, scalable and transparent to users. Protocols and messages exchanged between the participating entities.
2. Ticketing System:
- tickets are used for authentication.
- Client connects with kerberos to request for ticket granting service (tgs) ticket.
- After getting tgs ticket, user/Client connects with TGS to get server ticket.
- After getting ticket for server, connect with server to service its request.
3. Mutual authentication between the client and server.
3. Kerberos Database Management Service: All writes/administration request changes are done to master copy; slave copies are read only.
4. Kerberos achieves higher availability and better performance through database replication.
5. Flexible enough to replace encryption mechanism and database implementation.

Learning:
Kerberos as a third party authentication protocol to access service in an open network system.

Confusing:
Why to send the entire database for maintaining consistency? Why not just the delta/difference between the previous and recent version? Also an update is sent every hour. Under some circumstances, a lot of updates might have happened during that hour and sometimes very few. How is it decided? Couldn't it be based on number of updates.

Summary:
This paper gives an overview of Kerberos, an authentication system designed by Miller and Neuman for open network computing environments, and describes their experience using it at MIT’s Project Athena.

Problem:
In a more open environment, the communicating channel is not secure, where users can completely control their workstations so that they can masquerade as a given server. In this case, a user needs to prove his identity for each requested service for the sake of access controlling. Three requirements are necessary for a identification under such circumstance:
1. The system should be secure. 2. The system should be reliable. 3. The system should be transparent to users. 4. The system should be scalable to support distributed system.

Contributions:
1. Design a third-party authentication service based on the model presented by Needham and Schroeder. Kerberos can be run as a stand alone service that providing authentication between client and server.
2. Decouple password authentication with the successive service request authentication by introducing service tickets. Using tickets can minimize the chance that the password will be compromised. Server tickets are also separated with TGS tickets so that 3-level protection is provided in Kerberos.
3. The kerberos system has been integrated with underlying operating system authentication system so that users would not notify its existence.

What is confusing:
1. During the valid time of one specific ticket (no matter which kind of ticket it is), is it possible that man-in-the-middle can steal this ticket and pretend as the user to do malicious operations to servers?
2. The master-slavers architecture is really good for scalability?

What I Learned:
A separate authentication system makes the whole system design modularized and replaceable. Also, using tickets is another excellent way for authentication instead of passing password directly.

Summary:
This paper introduces the authentication service that is Kerberos created for user authentication, message authentication, and message encryption. Although the system is quite old, it has survived to be used in many enterprise companies even today due to its pluggable, secure, reliable, transparent, and scalable design.

Problems:
The problems the authors were trying to solve were authenticating users and services between each other in a secure way with the ability to add network encryption if needed.

Contributions:
The contributions in this paper included:
• Clear definitions for the different terms used in the context of Kerberos. Nowadays these conventions are still precisely as described in this paper.]
• A protocol for private key authentication along with a private session key derivation for establishing connections between clients and servers, or services with other services.
• A separation between the read only data-plane for credentials and the read-write control-plane for administration of those credentials.
• Several practical applications of using Kerberos such as:
o Secure rlogin and rsh
o Authenticated POP email
o A detailed extension of Sun’s File System using Kerberos

Unclear:
It was unclear to me why this service utilized private key cryptography only for authentication. Public key cryptography such as used in SSH or SSL/TLS may have made some of the requests shorter and also reduced the number of requests made overall.

Learned:
I learned about how a central key managing authority as used in Kerberos can be used simply to add authentication and network security in a distributed system. Using only private key cryptography and a ticket-granting service, private sessions between clients and servers whether human or programs can be mutually authenticated and established. The cryptographic algorithms like DES using CBC can easily be updated along with the master-slave key storage to support a more resilient modern day design. With these improvements I could see how it is a requirement for most large enterprises that require security.

Summary:
In this paper authors have described Kerberos, a trusted third party authentication service used to authenticate clients and servers in an open network computing environment and provide mechanism for secure communication between client and server nodes. Kerberos maintains a database of its clients and their private keys, and uses this information to generate tickets/authenticators which the specified user and the server can use for purpose of authentication and secure communication. Authors have also presented the perspective of various stakeholders in the system and have shown its applicability in SUN NFS and Project Athena.

Problem:
In open networks, where the client nodes cannot be relied on to identify its users correctly, the network services running in such environment need a common means of authenticating their users and vice-versa. The authentication service should be outside the consumers and producers of network service and should be secure, highly reliable, scalable and transparent to the users. Kerberos solves this problem by providing a secure third-party authentication service which provide protocol for authenticating users and a mechanism for secure communication between them.

Contribution:
-The idea of using private keys which are known only to the client and the Kerberos server provide the basis that everyone can trust the Kerberos server in order to
trust other clients or servers.
-The generation of temporary private keys (as session keys) which can be used to encrypt messages between two parties, to enable secure communication between them.
-The provision for three level of protection: Simple authentication, safe messages, and private messages, provide consumer services flexibility in using the kerberos system as per their requirements.
-Use of timestamps in tickets to provide protection from replay attacks.
-The use of tickets with suitable timeouts so that client do not need to re-authenticate multiple times achieves a level of transparency.
-Implementation of software components as replaceable modules such as encryption library, database library.
-Provision for simple extension of architecture by using cross-realm authentications.
-Use of checksum to provide additional security while replicating data from master database to slave database.

Confusing:
- What is the requirement for sending the master database in its entirety each time for updating the replicated database instances. This process can be very slow as number of clients grow large. Do the current version of Kerberos implementation still follow this same approach for replication?

Learned:
-Using of trusted third-party authentication service makes providing security much simpler than it would have been without one.
-Also learned how encryption using private key can be used to implement different functionality of an authentication service.

Summary: This paper introduces Kerberos, an third-party authentication service for open network systems (the clients and servers are not trustable). They introduces tiackets (timely identity of server and client), the protocol for authenticate client, the database of Kerberos, and the applicability.

Problem: In an open network systems, the clients and servers are changing frequently and are untrustable. People needs to authenticate of clients and services, which has the following features:
1. Security, information can hardly be circumventing.
2. reliability, the authentication service should not down.
3. transparency, the user almost cannot feel the existence of the authentication service.
4. scalability, many heterogeneous systems should be able to authenticate.

Contributions:
1. The idea of third-party authentication system makes the security another layer on the open network system, allows hetorogeneous system authentication. The protocol, database is isolated from other parts of the network system.

2. The tickets is used widely to authenticate a client and service pair. Ticket is a (encrypted) package with timely information about the identity of client and service. Tickets make the authentication protocol simple the transparent to users.

3. The database of Kerberos is based on master slave structure. The client information is replicated among nodes (one master + multiple slaves), where only the master's database can be read and write, the slaves' database is read-only. The snapshot is periodically replicated to slave databases. This master-slave and slave read-only fashion improves the reliability.

Confusion: The tickets contains timestamps and is available in one session to prevent replay attack, however, the correct perform of timestamp relies on the synchronization of clocks between client and server. Does the synchronization always holds? Is it necessary to use some relative logical clocks to replace the timestamp?

Things I learned: The idea of provide a third-party authentication service, which makes the security simpler.

Summary:
This paper introduced Kerberos, a trusted third-party authentication service.

Problem:
In a network of users requiring services from many separate computer, the system must be able to honor requests from hosts that are not under organizational control. Thus the user must prove her/his identity for each desired service. The server must also prove its identity. The identification system needs to be secure, reliable, scalable and transparent.

Contributions:
(1) Provide two kinds of credentials based on private key encryption tickets and authenticators. The user first requests the ticket-granting service. Then a random session key and a ticket will be generated, which will be sent back to the client, under private key encryption. Then user password is required and converted to DES key. Once exchange is completed, session key and ticket secure the communication between client and server. Clock should be synchronized to prevent replay.
(2）Design a new authentication protocol between Kerberos, TGS, Server and User/Client.
(3) Provide KDBM service. Changes are only made to the master database and slave copies are read-only. The master-slave design increase the availability of system and fault tolerance. The database is dumped every hour to keep consistency. When KDBM server receives a request, it will first compare the authenticated principal name of the requester of the change to the principal name of the target of the request. ACL will be further consulted if they are not the same.
(4) It is transparent to users. the user will hardly notice that Kerberos is present.

Learned:
This paper gives a good example of how public/private key pairs are used in communication encryption. The availability of private key secure the content of message. Besides, the modular design of system and protocol is very important. Highly modular design means different parts can be replaced (such as the database system used) and improve the flexibility of system. The Kerberos, TGS, Server and Client authentication protocol is quite clear and direct.

Confusion:
Are Kerberos, TGS, Server on multiple physical machines or in a single machine? There are 5 hops before the client can finally send request to the server. This can greatly reduce the performance under some extreme situation. Besides, how is client's private key negotiated without being leaked to other attackers?

Summary:
Kerberos, a scalable, distributed, reliable, secure system for authenticating remote users for a service. Kerberos system involves a client for the service, kerberos client, server which hosts a service, master and slave database to store password an access control of the users. Kerebros proposes a three step protocol, 1) user is authenticated by the kerebros server which gives a session key to the client to talk with the ticket grant server, 2) Then the client gets the ticket to talk to the server from the TGS, when the client gives the session key to TGS, 3) Client talks to the server with the ticket from TGS to access the service.

Problem:
All the systems which provides security, has the authentication and user credential closely tied to each other which makes the implementation cumbersome and error prone. Systems should be able to pass the replay faults. Also, there were no systems, which support scalable and modular services which supports flexible authentication and single sign on password with increased security using encrypted passwords.

Contributions:

1. Kerebros proposed a scalable, distributed secure system with third party user management.
2. Kerebros server, which hosts the master database which verifies the user's credentials using private key using the user's password.
3. The client gets a session key from the server, and gets the ticket from TGS. Client uses the ticket to talk to server.
4. With kerebros server and TGS, the system is very similar to single sign-in by Google, which supports different google services using single password.
5. Kerebros just uses a private key to encrypt the data, instead of public key and private key.
6. Database is made reliable by maintaining replications with lesser permissions in slave nodes.
7. Consistency is maintained using dumping th database contents every hour and sending it to slave nodes.

Confusing:
I don't know how the authentication forwarding can be solved using kerebros with little modifications.

Learned:
I learned how to design a reliable, scalable secure system using modular approach like kerebros.

Summary :
Kerberos is a third party authentication service which can be used to authenticate clients and servers in a public network. The authors designed this using private key encryption and authentication protocols. Kerberos is a reliable, secure, scalable and transparent authentication system that’s very convenient for users to authenticate with.

Problem :
In an open network environment, authenticating clients to servers and servers to clients is very important because neither can be completely trusted. Building an authentication module as a separate entity not part of the existing server makes it a very scalable, flexible solution.

Contributions :
1. Modularizing components like encryption and database services so that it is possible to replace these with any other algorithm/service.
2. Ensuring transparency to the users in a way that once the users enter their password, the tickets issued by the ticket generating service takes care of the connections with the subsequent servers (for a lifetime) without the user having to give his password consecutively.
3. Kerberos supports different kind of security levels based on the user’s needs and also allows for users to operate in different roles defined by parameter “instance” which shows how flexible it can be used as.

What I found confusing :
The paper talks about servers contacting servers on behalf of the user in open problems. But they also say that their current mechanism can be extended to do this. This part is confusing for me. How can this actually be done?

What I learned :
Decoupling authentication mechanism from the actual server is a very desirable approach to handling security. I also learned how to make security as transparent as possible to the users using tickets and session keys.

Summary: Kerberos is a trusted third-party authentication service that allows untrusted clients (users and hosts) and servers to mutually authenticate themselves over an untrusted network. This paper describes Kerberos' authentication protocols, implementation choices for scalability and reliability, as well as the user and application programming interfaces.

Problem: Network is open: clients and servers are not under central control. This mandates authentication for securing access to services. Network may have eavesdroppers capable of reading cleartext messages and replaying encrypted ones. For convenience, users should only be required to sign on once and the per-server authentication should be transparent. Scalability and reliability are important concerns as in any distributed setting.

Contributions:
* The trusted authentication service authenticates clients using shared private key, and then provides auto-expiring tickets that allow the clients to authenticate themselves to servers thereafter.
* Public/private key encryption is used for authentication and connection establishment: the rest of the messages are encrypted (when necessary) using symmetric key encryption (using shared session keys). This is improves efficiency, while foiling eavesdroppers.
* Timestamps in tickets prevent replay attacks. Auto-expiry of the tickets limits the damage from stolen credentials or revocation.
* Mutual authentication is also possible: clients can authenticate servers also through Kerberos.
* The concept of realms in the Kerberos naming system allows multiple administrative domains to share the same authentication system. Cross-realm authentication is flexible enough to support different levels of trust for domains in chained authentication.
* Authentication is a read-heavy workload. Kerberos is scaled for reads through master-slave replication of the directory. Consistency is maintained using writes at master only.
* The modular design allows the use of different encryption libraries and backing databases.

Learning:
* The idea of decoupling and abstracting out key functionality is a powerful one in scalable, performant software design. Here, authentication and message encryption (session key generation and exchange) are provided using a separate third-party service that can easily be plugged in transparently into applications.
* It's amazing how the simple concept of using tickets and authenticators can avoid password re-entry without compromising security across accesses to multiple services, possibly spread across multiple administrative domains.

Confusion: Should a per-service ticket necessarily be generated by the 3rd party TGS? Could we design it so the clients can use an authenticator-issued certificate to identify itself to servers, which then directly perform access control? This would avoid an additional round-trip communication and layer of indirection.

Summary:
The paper presents an authentication service that ensures security when entities cannot be trusted. Kerberos allows user and clients (Kerberos views them the same essentially) to authenticate to servers providing services (e.g. a networked file system) and also alldows these servers to authenticate to users. This is done via a trusted third-party (i.e. the Kerberos service) and allows to communication to proceed un/encrypted as desired by the application using Kerberos once the client and server have authenticated with each other establishing the handshake of trust.

Problem:
The authors are attempting the issue of establishing trust in an open (and therefore untrustworthy) environment. Essentially they needed a protocol that would allow users, clients (applications, machines), and servers (services) to authenticate both ways with one another so each could be confident they are talking to the entity someone claims to be. They wanted to do this in a way that was transparent to the user (for the most part).

Contributions:
- The software components and libraries that make up the Kerberos service (as well as their modularity which allows components to be swapped easily (e.g. the encryption algorithm).
- The Kerberos protocol that allows users, clients, and servers of a realm to authenticate each other via the Kerberos service running over that realm (they also explain how authentication can be established between to Kerberos services and therefore user, clients, and servers of different realms).
- The Kerberos ticket which is the main component that allows their system to work without requiring a prompt for a password on each request to a new service.
- The different views provided by Kerberos for users programmers, and admins.
- The different levels of encryption available for messages between a client and server after authentication is established.

Learned:
I learned about the Kerberos protocol and its use of tickets and authenticators to establish trust between a user, client, and server. I also did not realize that Kerberos was used by many applications during a single session (which speaks to the success of this being transparent) through use of the ticket generated during login to a machine.

Confused:
I was a bit confused when they talked about encrypting messages as they always used the secret key of either the client or server. For instance I though generally when a server sends to client they encrypt with the client's public key. This means only the client (with their private key) can decrypt the message. If the server in fact encrypted with the client's private key (which it does know) couldn't any machine with the public key decrypt the message? Or is this an encryption scheme that does not use public/private key pairs?

SUMMARY: The authors present a network authentication system called KERBEROS which provides a secure single sign-on to access multiple services.

PROBLEM: Users wish to log in, once preferably, and be able to access everything they are allowed to. Further, let's assume that the network is hostile, a fair question is, "How do servers authenticate this user, and how do we know if they are allowed to access a server?". Another questions is, "How do users know they have contacted the correct service?". Kerberos provides solutions to all of these issues.

CONTRIBUTIONS:
- Kerberos makes a clean distinction between users (humans), clients, servers, hosts, and services.
- Having a single sign-on (TGT) allows users to access multiple services conveniently.
- The server can issue "Authenticators" which are not interpretable by clients but must be given back to the server to be "Authentic".
- Each service requested (using the TGT) provides an audit source on the server side.
- Access to each service is temporary (depending on the window), so the capturing of a KERBEROS ticket does not give an attacker unlimited access forever.

CONFUSION: It seems that cross-realm authentication needs manual configuration of trusted realms. There is no central service for this, as there is no central authority of the entire Internet. That said, there is no peer-to-peer delegation of trust. So, I question if the system can scale across administrative boundaries.

LEARNED: It was a good refresher on the motivation. I also read the "Theater Version": http://web.mit.edu/kerberos/dialogue.html

Summary:
This paper discusses the design and implementation of Kerberos authentication service for the Athena system. Kerberos provides a way for a trusted third-party authentication service to be be used to verify identities of users in a system. In an open network environment, this is crucial since the local workstations cannot verify the identities of users connecting or trying to use it.

Problem:
In a non-network environment, resources and confidential information can be protected by physically securing a particular machine. For a networked system, it may be desirable to implement authorization to ensure protection. The first step in this is to authenticate entities in the system. If the machines belong to some organization control, it is possible to trust the individual work stations. But in a very diverse environment (like Athena) where any user with his/her own machine can request access to resources in the system, there is a need for authenticating users even if their machines are not under any organization control. Kerberos solves this problem.

Contributions:
1. Ticket Bootstrapping - At a high level, to access any service, a client needs a ticket to that service. The tickets are granted by a special service called as the Ticket Granting Service. To get access to the TGS, the user when logs into a machine, is directed to the authentication service. The user enters his/her password. The authentication server checks if it knows this entity and sends a Ticket for the TGS which is encrypted using TGS's key. Also a random session key is included which can be used by the client to talk to TGS. The ticket together with the session key is encrypted with Client's key.

2. Server - Client authentication - Once the client has obtained a ticket to a service, the client can send the ticket to authenticate itself to the server. The server authenticates itself by incrementing the incoming timestamp and sending it back to the client.

3. The paper also provides an overview of how kerberos databases can be organized for high availability. It also presents some admin utilities to manage identities in the kerberos database.

Confusions:
1. There is problem of users seeing inconsistent kerberos dbs since the updates are not ensuring strict consistency between master and slaves. This problem is very similar to GrapeVine (They advise to pick the same registry server for successive operations). Here, It is not clear how they solve it.

2. It is not clear what happens when the TGS goes down. No tickets can be granted and no can use any service?

What I learned:
I learned how authentication service can be cleanly separated from the original services. And also how authorization and accounting can become easy when authentication is in place.

Summary:
This paper introduces Kerberos, a trusted third-party authentication service, which can be used to verify users’ identities for servers and servers’ identities for users. It’s secure, reliable and transparent to users. The authors also discuss the integration of Kerberos to Network File System.

Problem:
- In an open network computing environment, the machines are not under organizational control, and users have complete control of their machines. In order to provide secure service to the user, the user must prove her/his identity for each desired service, and the server must prove its identity for the users as well.
- Since users and servers don’t trust each others, there should be a third-party to provide authentication services for them.
- The identification mechanism in the authentication service must be secure, reliable and transparent to users. It should be easy to be integrated with existing distributed applications.
- The implementation of authentication system should be flexible, and easy to be upgraded to use new encryption techniques.

Contributions:
- This paper discusses the requirements for an authentication service, and introduces the design of Kerberos to fulfill these requirements.
- Read-write (administration server) and read-only (authentication server) servers are separated. This separation is good for scalability, because we it’s easy to scale read-only server with multiple instances. Normally we need only one read-write server, so the job to maintain consistency between all the servers are straightforward.
- Two different credentials - tickets and authenticators, are used for different purposes. The ticket has amount of lifetime, but the authenticator can be used only once. During the lifetime of TGS ticket, users don’t need to input password to request new service because the client library and TGS can generate service ticket without user’s involvement, that’s convenient. The communication between user and server is secured by the session keys.

Learned:
Kerberos is a classical implementation of authentication system. What I learn from this paper is the understanding of the design choices about functions split-up and protocol, and how to use the encryption techniques to build secure, scalable and reliable authentication systems.

Discussion:
I am confused about the database propagation solution in Kerberos. The paper mentioned that the master database is dumped every hour, and then the database is sent in its entirety to the slave machines. That means the delay to propagate database update to all slave databases would be high. In practice, after the administrator creates a new account for one user, if the user’s authentication server uses a slave database, the user needs to wait for quite a long time to use the authentication service.
I don’t clearly understand the integration of Kerberos and NFS. Does the user need to re-mount NFS folder after the lifetime of the TGS ticket? I am interested in the integration of Kerberos with the latest NFS, but that’s out of the scope of this paper, I will get that information from other sources.

Summary: Paper presents Kerberos, an authentication system that allows users to gain access to services securely with the knowledge that the service is what they say it is and that the service knows who the client is. Basically, Kerberos is itself a service whose only purpose is to set up authentication between clients and services. All user information is kept in a database that is replicated.

Problem: Like with SFS, we have a problem with getting knowledge of the veracity of both users and services that the users use over an untrusted network. With SFS, their goal was to achieve a system that was egalitarian that didn't rely on a central authority to verify servers while leaving client authentication more of an open issue. Kerberos is able to address both server and client authentication by taking a middle-ground between being completely egalitarian and a centrally located totally trusted authority.

Contribution: The main contribution of this work is the description of the authentication service known as Kerberos. The system described is very simple and elegant, achieving secure authentication for the clients who use it.

Kerberos is divided into two parts, the authentication and administration parts. The administrative part of Kerberos is responsible for adding users and adding/changing the passwords of users in the database. The authentication service is where the real meat of the system is.

The protocol used by the authentication service is fairly simple. Since one of the goals of the system is to be as transparent as possible to users, from the users point of view, it should be just like logging onto a workstation. That is, entering a password. Behind the scenes, however, the client is contacting the Kerberos server and asking for a ticket to the ticketgiving server. This is the point where the user enters the password, thus verifying itself to Kerberos. Using the ticket given to it by the Kerberos server, it goes to the ticketgiving service to get a ticket for the actual service it wants to use. Using this ticket, it can then go to the service it wants to use and request the service.

Tickets have a set lifetime to them. The reason for this is to limit the damage that can be done if that ticket is grabbed by an adversary, say, if the user forgot to log off of their workstation. Tickets can't just be stolen and used; they have to be used in conjunction with a client’s authenticator in order to be useful. This is one of the only spots that a user would be aware that Kerberos is running underneath because, when a ticket expires, the service will no longer accept the client’s requests and the user would have to go back and start the process over again for another ticket (reentering their password).

User information is stored on a database that is replicated every hour to slaves. Only administrative actions can be done on the master. Authentication can be done on the slaves.

Confusion: How does Kerberos prevent a compromised password from being used during the time between it has been changed and before it is replicated to the slaves? For instance, say a user knows its password has been compromised. They immediately change it in the database. However, during the 1 hour period between the change and the replication, it seems that an adversary could authenticate themselves to Kerberos by connecting to the slaves and be able to do some damage.

Learned: Got a better understanding on how key encryption can be used to guarantee authenticity between entities. While the SFS paper did this differently, that paper in conjunction with this one has helped make this clearer.

Summary
This paper describes the design and implementation of kerberos a third party authentication service for services across the network. It also talks about the practical application of the authentication system at MIT's project Athena and lists some of the open issues with the system.

Problem
The problem the authors are trying to solve is authentication of clients to servers and vice versa in a networked environment where hosts and users cannot be trusted.

Contributions
1. Devised a third party authentication protocol that mostly works in a client transparent manner. The whole authentication process is decoupled from clients and servers.

2. Uses private key encryption for secure communication between kerberos principals and servers.

3. Uses a session key to encrypt messages sent between the client and server.

4. Client is being prompted for the password just once and the tickets can be issued multiple times completely transparent to the client.
5. Offers flexibility in terms of varying levels of security . One can have the user authenticated once per session or once per message and can have the messages encrypted with session key as well as authentication per message (Private messages).

6. Prevents replay attacks by recording the timestamp and logging all the previous requests received.

7. Divides the database based on functionality into administrative servers, authentication servers , servers that contain supplemental information like phone numbers etc so that these information can be secured at different levels.

8. The updates are propagated in a secure manner using encryption and checksum.

9. Interaction with other kerberos servers permitting authentication across administrative domains.

One thing I learnt:
Having multiple ticket granting servers for each of the services can aid in providing security in an efficient and flexible way. For instance google services could have one ticket for a set of its services thus, behaving like a single sign on environment.

One thing I found confusing:
I did not understand the authentication forwarding problem clearly.

The paper talks about Kerberos, which is a trusted third party service used to authenticate users and clients. The protocol works using the concept of tickets. The paper also talks about how the protocol satisfies the requirements of security, reliability and transparency to the user.

Contributions :

1. Uses an authentication server which is the main component that authenticates the clients based on their passwords and provides them access to the ticket granting service. Also grants tickets for admin requests.
2. The protocol uses symmetric key encryption to make the communication secure.
3. Ticket granting server provides the tickets for other services. Tickets are encrypted and are used as a proof of identity of the client to the server. They are valid for a specific lifetime and they contain a session key that is used for further message communication with that server. Avoid re-authentication until the ticket expires.
4. Authenticators are like one-time credentials encrypted using session key of the ticket that are used to grant access of a service to a client.
5. The protocol also provides mutual authentication between the client and the server.
6. The database for Kerberos is replicated for good availability. Database replication uses checksums to verify that that the database has not been subject to any data tampering.
7. Also enables cross realm authentication which allows a client/user to authenticate to a set of realms connecting to the actual realm which hosts the service.
8. Encryption mechanism and the database implementation can be replaced by any other implementation.
9. Transparent to the user until the tickets expire and the user has to re-authenticate.

Learning :

I mainly learnt the mechanism of using tickets and authenticators along with encryption to provide the authentication required to access a service.

Confusing :

Database replication from master to slave happens with the master sending the database to its slaves every hour. Sending the entire database is a huge network overhead. Can it use other mechanisms which only send recent update lists? The protocol depends on the assumption that the clocks are synchronized. When that is not the case and there is a drift, then comparing the times so as to determine the validity of the tickets is going to be faulty.

Summary
Kerberos enables mutual authentication between producers and consumers of a service. The requirements of Kerberos is that it must provide this authentication service in a secure, reliable, scalable yet transparent manner. Decoupling authentication into a trusted service such as Kerberos enables providers of services to register with the authentication service as do clients that wish to access those services, and allows Kerberos to perform the negotiation.

Problem
As the abstract states, in an open network computing environment, a workstation cannot be trusted to correctly identify its users correctly to network services. Kerberos provides an authentication service outside of the producers and consumers of this service to verify identities.

Contributions

• Decoupling authentication from the providers and consumers of the service. Systems that require authentication can do so by registering with the Kerberos service, and having its users authenticate through it.


• The level of indirection provided by the TGS provides the transparency to the users. After a single authentication with a password on a workstation, users can access subsequent services with the ticket to the TGS for subsequent service authentications.


• Passwords are never sent over the wire. Because the Kerberos system is also aware of the user’s passwords, the one way hash to generate the client’s private key enables authentication without both sides exchanging passwords over an untrusted network.

What’s confusing
How is authentication revocation handled? Wouldn’t revoked credentials persist for the period of time in which the TGS ticket is valid?

What I learnt
It’s possible to decouple authentication into a separate service that can be used to establish mutual trust between two untrusted entities over an untrusted network.

Summary:
Kerebos provides a trusted 3rd party authentication service which allows mutual authentication for both user and server identities in an open network computing environment. The Kerebos system uses private key encryption for secure authentication in an untrusted environment where eavesdropping is possible. The Kerebos ticket granting service (TGS) allows a client to authenticate for a finite period of time with any given service. The Kerebos Database Manament Service (KDBM) allows users to change passwords, or perform other actions if the requestors principle name is authorized in the ACL.

Problem:
How do we authenticate users and services outside of a trusted region in an open network environment where eavesdropping is possible? The goal of Kerebos is to provide a secure, reliable, scalable authentication service that could support the Athena project by allowing users to prove their identity to many different services.

Contributions:
1-Protocol: tickets and authenticators allow for mutual authentication in an untrusted environment. Granting tickets through the TGT for a period of time also allows some scalability. The system isn’t naive; replay attacks are blocked with clever use of timestamps, and the window for an attack is also limited to the lifetime of the ticket which can be made arbitrarily short if needed.

2-Replication for read (but not write) scalability of KDBM: scalability for reads are possible since read-only slaves can replicate a master server. This doesn’t help write scaling since all write operations must go to the master (this also makes the master a SPOF).

3-Data consistency: the master runs krop and encrypts the database checksum using the shared master database key and sends it to each kpropd process which runs on each respective slave. The slave only runs the update if the checksums match.

4-Secure: All passwords are encrypted with the master database key to protect data while it is sent over the network, thus preventing eavesdroppers from gaining useful information. Both master and slave machines share the Kerebos master database key.

What I Found Confusing:
They say the system is scalable, however, writes can only go to the master server. Hence, only read operations can potentially scale and it seems the protocol for doing this is not mentioned. Did they expect a read-heavy workload? Do they have a protocol for distributing reads among the slaves? Also, replication was delayed an hour; this seems like it could potentially complicate read operations on the slaves (staleness).

I thought using a chain of Kerebos servers for authentication through a series of realms was an interesting solution. Is Kerebos a viable alternative to ssl? If it is, why does it seem like SSL ‘won’?

What I Learned:
A 3rd party service can identify both users and servers and provided a trusted, secure service in a potentially hostile environment where eavesdropping is possible.

Summary:

The paper describes Kerberos, a trusted third-party authentication service used to verify users' identities. It describes the authentication model, the protocol, Kerberos database management, the perspective of the various stakeholders in the system, and shows how it can be applied to NFS.

Problem:

In an open environment, one cannot assume the hosts in the network to be trusted since they might not be under the organization's control. Users have complete control over their workstation, and impostor servers may deceive users. Mutual authentication for both the client and the server is required, and we must be able to protect against eavesdroppers and replay attacks.

Contributions:

- Widely applicable mechanism: Kerberos has been widely adopted in both Windows and UNIX environments.
- Largely transparent mechanism where the underlying shell/OS can perform Kerberos related actions on behalf of the user. It is similar to Single Sign On where the user enters his password once, and other credentials can transparently be obtained on his behalf.
- Mutual authentication where both the clients and servers can verify each others' identity instead of requiring separate protocols for each.
- Ticket based authentication mechanism with expiry allows parameterization depending on the security levels required.
- Provides distinct protection mechanisms where application programmer can specify what level of security they want instead of imposing choices on them: initial authentication, safe messages and private messages.
- Support for roles where a user might login as a normal user, or admin for performing different tasks.
- Tamper proof and encrypted DB update propagation mechanism.
- Mechanism allows support for cross-realm authentication.

One thing I found confusing:

Who is the trusted third-party in cross-realm authentication?

One thing I learned from paper:

I got an idea of how one might implement Single Sign On.

Summary:
Kerberos provides an authentication mechanism for computers connected via a network which don't know the authenticity of each other previously. That is, the computers aren't part of any closed group but can be any new client or server on the internet. This requires a Kerberos server for letting each principal(a client of kerberos) to verify the identity of the other principals to which some form of communcation needs to be established.

Problem:
If multiple computers are connected in a closed system, i.e. the administrator knows the identities of all the systems in the network, then the process of authenticating the user can be based on the individual machines itself. But in a network where the computers don't know the identities of others, there needs to be some protocol to trust the other computers. Kerberos solves this problem by coming up with a protocol using which all the computers (servers and clients) can communicate with each other in a secure way.

Contribution:
1. The concept of using private keys which are known only to the client and the Kerberos server laid the foundation that everyone can trust the Kerberos server in order to trust other clients / servers.
2. The idea of using session keys between 2 principals to encrypt messages between them was very useful for secure communication of messages.
3. The idea of providing 3 levels of protection(only authentication, safe messages and private messsages) allows the applications to use kerberos according to the level of security it needs.
4. The idea of using tickets so that the client doesn't need to reauthenticate itself multiple times is helpful.
5. Developing the software components(eg. encryption library and database library) in a modular fashion will help the process of plugging in different libraries easy.
6. Separating the process of authenticating each message (using authenticators) from the tickets is very useful since the client's can generate the authenticators and encrypt it using it's private key.
7. The idea of separating Kerberos authentication server from the TGS(Ticket granting Server) was important since multiple organizations can have their own TGS but they can use the same Kerberos server for inter-organization communication.

Thing I found confusing:
If multiple organizations can have their own Kerberos realms, then what would happen if an attacker can create his/her own Kerberos realm and attack other people in other realms that are using the same Kerberos server ?

Thing I learnt:
I learnt that technical ideas can be communicated in such a neat and simple way. I also learnt multiple credentials like tickets and authenticators can be combined to provide security in an efficient way in a system of open networked computers.

Summary: Kerberos provides a distributed authentication scheme for a networked environment, allowing clients to authenticate themselves to servers.

Problem: In a networked environment, there are multiple servers that provide services, but they do not have a common means of authenticating clients. They have no way to coordinate with other servers to know what clients have what identities/keys. One approach would be to have a central server with which to authenticate every client request -- this would be cumbersome, slow and less available.

Contributions:

• a user's (human) password is used as a key for both authenticating the server to the client, and also preserving the confidentiality of the newly generated session key.


• the client is provided with a token that can be used to obtain tokens to access specific services


• the client doesn't have access to all the services, but only the ones for which it requests access

Confusing: the writers punt on the problem of time. This seems like a big problem! How do they ensure that all the clocks are synchronized? Is it fair to assume that the clocks are synchronized? Is there an alternative that doesn't involve physical clocks? Could Lamport's work on clocks and time be applied to this?
Also, how is it secure to store the user's password on the server? How can a password have enough entropy for a secure key?
Learned: a client can authenticate itself to a server without having to send a password or prove a key: it can authenticate itself by decrypting a message that was encrypted with its key. It seems like it's a reversal of other schemes, like SSL.

Summary: This paper introduced an authentication service called Kerberos. Kerberos can be added on top of any open network systems, providing authentication services to both users and servers.

Problem: Authenticating the identity of the user or the server is essential to many services, especially when the system is built in an open network environment, where none of the parties can be trusted. Though it is possible to modify the existing services to add a security layer, it is most desirable to implement a dedicated authentication service that can be shared among many services.

Contributions:
1. Isolated authentication from the system. By doing this we can make any existing system more secure without modifying them a lot. Moreover, the isolation makes it possible to keep the authentication server with more security barriers than any other services. For example, there are usually more security mechanisms set up on the the authentication server than on a file system server.

2. A protocol that allows both parties authenticate the identity of each other in an untrusted network. Each user's contact with the authentication server will be using a ticket that includes information necessary to make sure the conversation is private.

3. Client data stored on a database working in a master slave fashion. That is, data is fully replicated among many nodes, and only one of the nodes is master. The master database can be read and written, while other slave nodes is read-only. Every hour a full snapshot is propagated to slave databases. This improved the availability of the database and meeting the consistency requirements.

Things confused me: In many modern authentication infrastructures, only the digest of users' password is stored on servers. In that way, even the database is compromised, attacker still cannot steal the identity of a user. However Kerberos will have to store the plaintext of users' password in database (or store something that can be used to recover users' plain password) because the protocol will use this password as the key of DES encryption. Moreover, databases are replicated so that the chances that these information being leaked is high. Is that really a good design?

Things I learned: How to isolate the authentication service and the main service using sessions and tickets.

Summary:
The paper summarizes the design and working of Kerberos, a third-party authentication service for user verification in an open network computing environment. Kerberos was designed for implementing the authentication service in Athena environment and aims for security, reliability, transparency, and scalability. It uses key encryption to pass the identity over the network and also to setup a session securely even in an insecure environment.

Problem:
Providing authentication service in a open network computing is non-trivial especially because the users of the service can be outside the trusted region of the authentication server itself. Making the authentication service scalable is a major problem, the authentication service must be replicable for availability and also be able to provide a sustained secure session between client and the server it wants to access.

Contributions:
• Kerberos aims to offer authentication services to hosts inside and outside the organization wherein the users have the liberty to login from their trusted workstation.
• Key idea - the clients rely on the Kerberos service for identifying each other and the identities of all the users including their passwords are stored in the Kerberos servers. Effectively it is the central authority for authentication.
• 2 types of credentials are used: Tickets - used to pass the identity of server/client and help setup a secure connection; Authenticators - used by the sender to authenticate itself. The client request the Kerberos for access to the service and a sequence of encrypted transactions between client and Kerberos provides the client with the session key which is then used to communicate with the service of interest.
• The main advantage of using the ticket and the session key is that the client can access the server securely for a predefined time without having to remember the password of the user, hence it’s more secure.
• Replication - Kerberos allows multiple read-only servers (authentication servers) but a single read-write server (administration server). The changes made to the admin server are propagated periodically to other auth servers and validated by checksum of the database propagated.
• Transparency - kerberos is transparent to the client as long as the ticket is valid for the session.

Confusion:
The paper mentions that the replication is achieved by sending the entire database from the admin server to the auth servers every hour. Why is it necessary to send the entire database when only the updates can be sent, like in rumor-mongering. Wouldn’t this also allow more frequent updates and better user experience?

Learning:
I learnt the implementation of a simple 3rd party authentication service that can be used in an open environment without worrying about the user credentials being compromised. Also I learnt how key encryption is used at all stages to achieve the functionality of Kerberos.

Summary:
Kerberos is a trusted third party authentication service which is used to authenticate the user and provide a secure communication between server and client machine. It does this by maintaining a database which contains credentials of users and servers and then using this information to generate tickets which only a specified user and server can use for which it is generated.

Contribution:
1. The main idea in the paper is the use of tickets to provide authentication. Whenever clients want to use some service from a server, first it contacts the kerberos authentication server by sending its name. Kerberos server check if the user exists and then reply back a message which is encrypted by using user's password (only that user can decrypt it). User is asked for its password to decrypt that message which contains ticket for tgs, session key. Then client sends an authenticator and ticket to the tgs which compare the content of both to verify the identity of the user. Then finally tgs send back the ticket to the server which host the required service.
This whole process of granting tickets is quite simple and secure which authenticate users to the servers. This also works across administrative realms if the two kerberos in two realm trust each other.
2. It avoids storing password locally on the user's machine or sending them over the internet.
3. It also provides a secure interface for the admins to add/remove pricipals(clients of kerberos) from the database. Individual users can use a separate program kpasswd to change their password in the database. These operations also uses the tickets. Here the tickets are granted for the KDBM service which maintains the database. Only the master KDBM server can make the changes and then these changes are propagated to the slave KDBM servers.

Confusion: The database updates from master to slaves happens slowly (paper mentioned every one hour). Would not that be weird for the users? For eg. A user change his password which is handled by the master. Then user try to use some service, authentication request for which is handled by slave server. At this point, the user's new password would not work if the slave server is not updated with the new password by the master.

Learned: Kerberos use the technique where the client's get two message from the server, one it can decrypt and the other cannot. This way the server client's want to access never has to contact kerberos to verify the client's user. If the client posses valid ticket (which kerberos provided) and can show that it is able to decrypt the other message, server can verify what client has send and be sure that it's the correct client.

Summary:

The paper presents architecture of Kerberos, a third party authentication service used to authenticate clients and servers in a public, open network, where users may request access from a self-managed workstation. Kerberos uses private keys for both authentication and encryption mechanisms; keys are used between the distributed components as well. The paper also discusses applicability of Kerberos implementation to Project Athena and SUN NFS.

Problem:

• In an real-world open network where there is no centralized control for the workstations, access control mechanisms become quite challenging as physically securing any machine will not help in entirety. So the mechanism should involve user specific authentication.
• Apart from authentication and secure communication prevention of reply attacks is also quite essential.
• The authentication mechanism should be strong enough to prevent any form of packet spoofing by doing a man-in-the-middle attack.

Contributions:

• The usage of tickets and authenticator for interaction between any two components ensures high level of security through encryption. Also making the authenticator one-time use only provides additional level of security from packet sniffing.
• Kerberos is made more flexible and transparent by allowing a lifetime for ticket rather than using it one-time.
• Using authentication server directly in KDBM operations; allowing admin changes by re-authenticating with user/admin password is highly used in many authentication mechanisms.
• Simple yet efficient means of countering replay attacks by using synchronized timestamps.
• Providing additional security by using checksums for DB replication operations(over the basic key based encryption).
• Simplicity of extending the architecture for cross-realm authentication by just introducing a shared key between the authentication server in the two realms.
• Automatic deletion of tickets and any related information when user logs out.

Unclear concept:

• Wouldn't TGS become a single point of failure if they are not doing any replication for it? If they need to do replication then, session key's need to be stored somewhere; currently they do not talk storage of session keys.
• From the authentication protocol, I wasn't clear if the server ticket is being encrypted by the server's private key; even during the decryption, they did not talk about the key being used.

Learning:

I learnt about the pre-authentication concept of using user's password in order to even obtain the TGT ticket. Lack of this step can lead to TGT being subjected to attack by malicious clients.

Summary:
The authors present the design of Kerberos, a computer network authentication protocol for open network computing environments. Kerberos consists of a third-party authentication service that allows nodes communicating over a non-secure network to prove each other’s identities securely. It uses symmetric key cryptography and provides security against replay attacks and eavesdropping. It was used for authentication across all services in project Athena at the time the paper was written.

Problem:
In a non-networked personal computing environment, resources and information can be protected by physically securing the personal computer. Whereas, in an open networking environment where users require services from many separate computers, we need mechanisms for users to prove their identity before requesting a service. Considering the environment, the mechanisms/protocol used should provide some guarantees wrt protection against attacks such as eavesdropping, replay attacks etc. It is also desirable for this authentication system to be transparent to the user.

Solution from the paper/Contribution:
The authors designed Kerberos as a third party authentication service which works on the basis of ‘tickets’. At a high level, there is an authentication server containing a database of users/passwords. The client authenticates with the Authentication Server which issues a ticket for communication between client and a ticket granting service. Using this ticket, the client is able to communicate with the ticket granting service which it uses to obtain tickets for communication with any other servers within the same realm or another trusted realm. The tickets are timestamped to prevent against replay attacks and messages are DES encrypted (symmetric key cryptography is used). The tickets are alive/valid only for a fixed duration after which the client will have to get a new ticket if it wishes to continue the communication.
The authentication database is replicated. There is a master which accepts all writes and many slaves which can be used for read-only. Kerberos has an eventual consistency model; the master periodically transmits the entire database to the slaves to propagate the updates. Checksums and encryption is used for security. The original Kerberos is mostly invisible to the user unless the session needs to be extended when the ticket times out. An administrator can modify the authentication database by adding principals or changing passwords; he uses the kadmin program. A normal user can only change their password; they use the kpasswd program. It also provides library functions which makes it easier for programmers to ‘kerberize’ their applications.

Issues:
Kerberos depends on local timestamps at the various machines and so it is very important for the system that the nodes are synchronized. Also, the master provides a single point of failure.

Key takeaway:
I’m not sure if this paper introduced the concept of a trusted third-party but for me that is the key takeaway from this paper. Having a trusted third-party makes providing security much simpler than it would have been without one.

What I found confusing:
The paragraph about realms was a bit confusing. So, if a user wants to use a service which is not in the same realm, then the two realms need to be trusted for communication to be allowed?? So a kerberos like system cannot be used in an Internet like setting where I may want to use a service which is mostly unknown and hence cannot be trusted!

Summary:
The authors present the design of Kerberos, a computer network authentication protocol for open network computing environments. Kerberos consists of a third-party authentication service that allows nodes communicating over a non-secure network to prove each other’s identities securely. It uses symmetric key cryptography and provides security against replay attacks and eavesdropping. It was used for authentication across all services in project Athena at the time the paper was written.

Problem:
In a non-networked personal computing environment, resources and information can be protected by physically securing the personal computer. Whereas, in an open networking environment where users require services from many separate computers, we need mechanisms for users to prove their identity before requesting a service. Considering the environment, the mechanisms/protocol used should provide some guarantees wrt protection against attacks such as eavesdropping, replay attacks etc. It is also desirable for this authentication system to be transparent to the user.

Solution from the paper/Contribution:
The authors designed Kerberos as a third party authentication service which works on the basis of ‘tickets’. At a high level, there is an authentication server containing a database of users/passwords. The client authenticates with the Authentication Server which issues a ticket for communication between client and a ticket granting service. Using this ticket, the client is able to communicate with the ticket granting service which it uses to obtain tickets for communication with any other servers within the same realm or another trusted realm. The tickets are timestamped to prevent against replay attacks and messages are DES encrypted (symmetric key cryptography is used). The tickets are alive/valid only for a fixed duration after which the client will have to get a new ticket if it wishes to continue the communication.
The authentication database is replicated. There is a master which accepts all writes and many slaves which can be used for read-only. Kerberos has an eventual consistency model; the master periodically transmits the entire database to the slaves to propagate the updates. Checksums and encryption is used for security. The original Kerberos is mostly invisible to the user unless the session needs to be extended when the ticket times out. An administrator can modify the authentication database by adding principals or changing passwords; he uses the kadmin program. A normal user can only change their password; they use the kpasswd program. It also provides library functions which makes it easier for programmers to ‘kerberize’ their applications.

Issues:
Kerberos depends on local timestamps at the various machines and so it is very important for the system that the nodes are synchronized. Also, the master provides a single point of failure.

Key takeaway:
I’m not sure if this paper introduced the concept of a trusted third-party but for me that is the key takeaway from this paper. Having a trusted third-party makes providing security much simpler than it would have been without one.

What I found confusing:
The paragraph about realms was a bit confusing. So, if a user wants to use a service which is not in the same realm, then the two realms need to be trusted for communication to be allowed?? So a kerberos like system cannot be used in an Internet like setting where I may want to use a service which is mostly unknown and hence cannot be trusted!