9

In Kerberos, the Authentication Server (AS) and the Ticket Granting Server (TGS) are generally implemented on the same server. This machine is called the Key Distribution Center (KDC).

Surely, it makes sense to implement these services on the same physical machine, as in small and medium-sized networks it would be overkill to separate these two services. Additionally, I have a relatively reliable source, which says (translated):

TGS and AS have to access the same DB => it doesn't make much sense to implement TGS and AS on different machines

However I don't see which database has to be shared between the two.

This is my idea, how I would separate AS and TGS, there are no shared databases:

  • As AS and TGS are separated, they have a different Master Secret
  • The AS has a database with all users with their respective master secret (used when the User signs in, to encrypt the session key), as well as the master secret of the TGS (to encrypt requested TGTs).
  • The TGS has a database, which allows it to determine which user is allowed to use which service (ACL, revocation list, ...), as well as a database with all services with their respective master secrets (to encrypt Tickets).

When a user wants to use a service (simplified):

  • Authenticate at the AS
  • Get a Ticket Granting Ticket (TGT), encrypted with the TGS Master Secret, as well as the session key, encrypted with the user's master secret.
  • Contact the TGS with the TGT
  • Get a Ticket, encrypted with the Service's Master Secret
  • Contact the Service with the Ticket

Am I missing something, or is there really no problem at all separating the AS and the TGS?

Misch
  • 193
  • 1
  • 5
  • 1
    It sounds like you're way too deep into Kerberos internals. The usual way to scale is to just add more KDCs, so I'm not really sure what you're trying to accomplish. – Michael Hampton Apr 18 '14 at 15:16
  • 1
    Right - what problem are you actually faced with, that you're trying to solve? – mfinni Apr 18 '14 at 15:34
  • 1
    I'm not trying to solve any concrete problem. I'm just trying to understand the Kerberos internals (for an exam) without actually wanting to use it at the moment. The question is a purely theoretical one, I just want to know whether I understood something wrong or if the quote in my question isn't totally right. – Misch Apr 18 '14 at 16:11

2 Answers2

4

Your question is all theory. So I'll answer in kind. The AS and the TGS are logical servers, and as such they could theoretically be separated. But in practice there has been no good reason to implement them on separate machines, and so no one does that in real life. Even the largest, busiest networks in the world in terms of Kerberos authentication have no need to separate out the logical components of the KDCs. In real-life implementations of Kerberos, all the data that the AS needs and all the data that the TGS needs is all stored in the same database. It could theoretically be separated but there is just no good reason to do so and would do nothing but needlessly complicate the implementation.

Ryan Ries
  • 55,011
  • 9
  • 138
  • 197
  • 1
    I just found another problem when separating AS and TGS: It is not only possible to get TGTs from the AS, but you can also ask for a ticket for any other service (eg if you know that you will only need this one ticket, so no need for the detour via TGT). This means that the AS additionally needs all the data I assumed only the TGS needs. – Misch Apr 24 '14 at 17:10
1

One reason I can think of the event of an attack on the Authentication Server when successful could bring down the Authentication Server rendering Tokens Issued and Secret Key (between TGS and AS) useless. The Client will then be denied access to the Application Server where the resources lie. Keeping them separate would then make sense until the lifetime of the issued token.

N_E
  • 107
  • 4