Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. No commercial use of these trademarks may be made without prior written permission of MIT. This RFC describes the concepts and model upon which the Kerberos network authentication system is based. It also specifies Version 5 of the Kerberos protocol.
|Published (Last):||1 February 2007|
|PDF File Size:||1.19 Mb|
|ePub File Size:||7.43 Mb|
|Price:||Free* [*Free Regsitration Required]|
Those not familiar with Kerberos may be bewildered by the need for numerous diverse keys to be transmitted around the network. In order to break down the complexity of the protocol, we will approach it in five steps: Step 1: Kerberos authentication is based on symmetric key cryptography. Step 3: A Kerberos ticket provides secure transport of a session key. Before starting to explore how Kerberos works, we must explain the notations that will be used in the illustrations: The u stands for user, s stands for resource server, and k stands for KDC.
S stands for session key; Sus means the session key shared between the user and the resource server. M stands for master key; Mu is the master key of the user. Drawing 1 in Figure 5. Figure 5. Drawing 2 represents the same session key, but this time encrypted. Drawing 3 represents the same session key, encrypted using the master key of the user. To ease reading we will talk about a "client," Alice, and a "resource server" that authenticates using Kerberos.
To be fully correct we should talk about the "service account of the service," but this would not promote ease of reading. From now on, the following words are synonyms: principal and security principal and entity, and domain and realm. It is very important to keep these assumptions in mind as we run through the Kerberos internals. Kerberos always deals with three entities: users, servers and a set of security servers that mediate between the users and the servers for authentication.
Time is trusted. This is because Kerberos uses timestamps to protect against replay attacks. The user trusts its workstation completely. This is because Kerberos caches authentication tokens on the client side. The security server must be online all the time. Kerberos requires the availability of the security server in order to generate new Kerberos security tokens.
The servers are stateless. Kerberos wants to limit the amount of security principal -- related information that is kept on the server side.
Kerberos looks at a user password as a weak secret -- it should be protected the best possible. One of the ways to do this is to limit its time on the user workstation. Another way is to create a key hierarchy.
Return to Table of Contents To authenticate entities Kerberos uses symmetric key cryptography When the Kerberos design was started, public key cryptography was still patented by RSA. This explains why the default Kerberos protocol as defined in RFC relies on symmetric key cryptography.
In symmetric key cryptography the communicating entities use the same key for both encryption and decryption. This is what happens when Alice wants to authenticate to a resource server using a symmetric key cipher illustrated in Figure 5. The resource server decrypts the message. If they are okay, Alice is authenticated to the server.
Why does this process authenticate Alice to the resource server? In this explanation you may have noticed the differences and similarities with the NTLM authentication protocol. Both Kerberos and NTLM use symmetric cryptography for authentication: "If you can prove you know your secret key, I believe you are who you say you are.
A session key exists between all Kerberos principals that want to authenticate to each other. A critical element in this exchange is the timestamp: It provides "authenticator uniqueness" and protects against replay attacks. Without the authenticator, a hacker could grab a ticket off the network and use it to impersonate Alice to a resource server.
The timestamp explains the time sensitivity of the Kerberos protocol and of Windows and Windows Server Remember from the introduction that Kerberos can provide "mutual" authentication: To provide this the Kerberos protocol includes an additional exchange that authenticates the server to the client.
In this example, it means that, in turn, the server will encrypt its name and the current timestamp and send it to Alice. A big problem when using a symmetric protocol is the secure distribution of the secret key. The secret key is generated at one side of the communication channel and should be sent to the other side of the communication channel in a secure way.
Secure means that the confidentiality and integrity of the key should be protected. If anybody could read the secret key when it is sent across the network, the whole authentication system becomes worthless: The secrecy of the secret key is a vital part of a symmetric cipher.
Steps 2, 3, and 4 explain how the Kerberos developers have resolved the problem of secure session key distribution. Return to Table of Contents The Kerberos protocol always deals with three entities: two entities that want to authenticate to one another and one entity that mediates between these two entities for authentication: the key distribution center KDC.
Why do we need a KDC? Suppose that Alice is part of a workgroup consisting of five entities that all want to authenticate to one another using symmetric key cryptography.
Because every entity needs to share a secret key with every other entity, we will need 10 keys. In a 50,employee company we would need about 1. Not only would we have to deal with an enormous amount of keys, but there would also be an enormous amount of small authentication databases: On every client there would be one, containing all the secret keys of the entities with which the client wants to authenticate. This solution is clearly not scalable to the level of a big environment.
Imagine having to use such a solution on the Internet. All entities trust the KDC to mediate in their mutual authentication. In Windows Server the KDC is a service that is installed on every domain controller as part of the dcpromo Active Directory installation process. The master KDC is collocated with a read-write copy of the authentication database single-master model.
As a consequence, a domain with multiple domain controllers provides fault tolerance for the authentication process and the authentication database. If one DC is down, another one can automatically take over. Also, the AD authentication database is replicated between domain controllers. The password is a secret key that is shared between each individual security principal and the central authentication authority in the Kerberos case the KDC. Both the entity and the KDC must know the master key before the actual Kerberos authentication process can take place.
For obvious security reasons, the AD never stores the plain password but a hashed version the hash algorithm used is MD4.
Return to Table of Contents Figure 5. Remember that in the first step we talked about the problem of distributing the secret key the session key when dealing with symmetric key ciphers. This section explains how Kerberos resolves this problem. It makes Figure 5. In Section 5. We also said that all entities trust the KDC to mediate in their mutual authentication.
Trust in this context also means that every entity trusts the KDC to generate session keys. In the scenario shown in Figure 5. So far, so good. Alice needs to authenticate to the resource server and requests a session key from the KDC.
The KDC will generate the session key5 and distribute it to both entities. After the KDC has generated the session key, it must communicate it to both Alice and the resource server. To secure the transport of the session key to a particular entity, Kerberos encrypts it with the master key of that entity. Only the Figure 5. By securing the transport of the session key using the master key, Kerberos creates what is known as a key hierarchy.
The session key is generated by the KDC. Because it is a critical part of the Kerberos authentication protocol, it is never sent in the clear over a communication channel: It is encrypted using the master key. The master key or long-term key : The master key is a secret key that is shared between each entity and the KDC. It must be known to both the entity and the KDC before the actual Kerberos protocol communication can take place.
The transport of the master key over a communication channel is secured using a secure channel. The secure channel: When Windows is using a secure channel, it is using a master key to secure the transport of another master key. The following example illustrates the secure channel concept. The concept of a secure channel was also explained in Chapter 2. In this key hierarchy the following are also true: Higher-level keys protect lower-level keys. Higher-level keying material has a longer lifetime than lower-level keying material.
Lower-level keying material is used more frequently for sending encrypted packets across the network. As a consequence, there is a higher risk for brute-force attacks on these packets. In other words, the associated keys should be changed more often. The first method has the following disadvantages: The resource server has to cache all the session keys: one session key for each client that wants to access a resource on the server.
This would impose a huge security risk on the server side. Synchronization problems could occur: The client could already be using the session key, while the resource server has not even received its copy yet.
Because of the disadvantages associated with Method 1, Kerberos uses the alternative explained next as Method 2 see Figure 5. Alice can decrypt the packet encrypted with her master key and get out the session key. Also, it takes away the need for the server to cache the tickets: It receives them from the clients as needed. This architecture makes the Kerberos protocol stateless on the server side. This has obvious advantages if you want to implement a load balancing or redundancy solution on the server side: There is no need to bother about keeping the session keys synchronized between the different domain controllers.
Five steps to using the Kerberos protocol
Naming Constraints Realm Names Principal Names Name of Server Principals Constants and Other Defined Values Host Address Types
Google Network Working Group C. Yu Category: Standards Track S. Hartman K. Please refer to the current edition of the Internet Official Protocol Standards" STD 1 for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document provides an overview and specification of Version 5 of the Kerberos protocol, and it obsoletes RFC to clarify aspects of the protocol and its intended use that require more detailed or clearer explanation than was provided in RFC
Please refer to the current edition of the "Internet Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document gives an overview and specification of Version 5 of the protocol for the Kerberos network authentication system. No commercial use of these trademarks may be made without prior written permission of MIT.
Several versions of the protocol exist; versions 1—3 occurred only internally at MIT. Kerberos version 4 was primarily designed by Steve Miller and Clifford Neuman. Neuman and John Kohl published version 5 in with the intention of overcoming existing limitations and security problems. The Swedish implementation was based on a limited version called eBones. This version obsoletes RFC , clarifies aspects of the protocol and intended use in a more detailed and clearer explanation. Founding sponsors include vendors such as Oracle , Apple Inc. Microsoft Windows[ edit ] Windows and later versions use Kerberos as its default authentication method.