Netzsicherheit Tutorial #10 - Das Ticket Granting Ticket

Summary

In diesem Video-Script geht es um Kerberos, ein Netzwerkprotokoll, das sich mit der sicheren Authentifizierung und Autorisierung von Benutzern in einem Netzwerk beschäftigt. Es erklärt, wie man ohne öffentliche Schlüsselkryptographie eine sichere Verbindung ohne Beteiligung von Langzeitgeheimnissen gewährleistet, was als perfekte Vorwärtsgeheimhaltung bezeichnet wird. Der Fokus liegt auf der Abfolge der Kommunikation zwischen Client, Authentifizierungsserver (AS) und Ticket-Gewährungsserver (TGS). Es wird erläutert, wie ein Benutzer (Alice) einen sogenannten Ticket-Gewährungs-Ticket erhält, das für die Kommunikation mit dem TGS verwendet wird. Der Prozess umfasst die Erstellung eines AS-Anfrage-Pakets, das AS-Antwort-Paket und die TGS-Anfrage, wobei besonderes Augenmerk auf die Verwendung von Nonce (einmalig vorkommende Zufallszahlen) und Zeitstempeln gelegt wird, um Replay-Angriffe zu verhindern. Der Inhalt des Ticket-Gewährungs-Tickets und seine Bedeutung für die sichere Kommunikation wird ebenso behandelt wie die Rolle des Sitzungsschlüssels und wie dieser sicher zwischen den beteiligten Parteien übertragen wird. Das Video schließt mit einer Vorschau auf die zukünftige Diskussion über die Antwort des TGS.

Takeaways

• 🔐 Kerberos ermöglicht es, auf Ressourcen zuzugreifen, ohne dass ein verschlüsseltes Netzwerk notwendig ist, und bietet gleichzeitig perfekte Vorwärtsgeheimhaltung.
• 🎟️ Um auf eine Ressource zugreifen zu können, benötigt man ein sogenanntes Ticket, das von einem Ticket-Gewährungs-Server zugewiesen wird.
• 🛡️ Der AS-Request (Authentication Server Request) enthält lediglich den Namen des Clients, die gewünschte Ticketdauer und einen zufälligen Nonce zur Sicherung gegen Replay-Angriffe.
• 📦 Die AS-Reply (Authentication Server Reply) enthält ein Ticket-Gewährungs-Ticket, das mit dem Master-Secret des KDC (Key Distribution Center) verschlüsselt ist.
• 🔑 Nur der Authentisierungsserver und der Ticket-Gewährungs-Server können das Ticket-Gewährungs-Ticket entschlüsseln, was die Sicherheit erhöht.
• 🗝️ Das Ticket-Gewährungs-Ticket enthält die Session-Key, die Alice (der Client) und der KDC für weitere Kommunikation verwenden.
• ⏱️ Die Session-Key ist mit dem aktuellen Server-Zeitstempel verknüpft, der ständig wechselt und somit nicht vorhersehbar ist.
• 📨 Wenn Alice mit dem Ticket-Gewährungs-Server kommuniziert, sendet sie eine TGS-Request (Ticket Granting Server Request), die einen Authenticator enthält.
• 🔗 Der Authenticator ist mit der Session-Key verschlüsselt und enthält den Namen des Clients und den aktuellen Zeitstempel.
• 📊 Das Ticket-Gewährungs-Ticket enthält auch den Namen des Clients, die IP-Adresse, die Session-Key, die Gültigkeitsdauer und einen Zeitstempel.
• 🕒 Die Gültigkeitsdauer des gewährten Tickets kann unterschiedlich sein als die des Ticket-Gewährungs-Tickets. Es definiert, wie lange der Client auf die Ressource zugreifen kann.
• 🔄 Der Prozess schützt vor Replay-Angriffe, da der Nonce und der Zeitstempel eindeutig und nur einmalig sein sollten.

Q & A

Was ist der Hauptzweck von Kerberos?

Kerberos dient dazu, sicherzustellen, dass Ressourcen in einem Netzwerk sicher zugänglich sind, ohne dass die Login-Daten ohne verschlüsselte Netzwerkverbindung missbraucht werden können, und gleichzeitig perfekte Vorwärtsgeheimhaltung zu gewährleisten.

Was ist ein Ticket im Kontext von Kerberos?

Ein Ticket ist ein Sicherheitsfeature von Kerberos, das es einem Benutzer ermöglicht, auf eine Ressource zuzugreifen. Es wird von einem sogenannten Ticket-Granting-Server (TGS) zugewiesen.

Was ist ein Ticket-Granting-Ticket (TGT)?

Ein Ticket-Granting-Ticket ist ein spezielles Ticket, das vom Ticket-Granting-Server (TGS) ausgestellt wird und erforderlich ist, um weitere Tickets für den Zugriff auf bestimmte Ressourcen zu erhalten.

Was ist ein AS-Request?

Ein AS-Request ist die Anforderung, die ein Client an den Authentifizierungsserver (AS) sendet, um ein Ticket-Granting-Ticket (TGT) zu erhalten. Es enthält normalerweise den Namen des Clients, die gewünschte Ticketdauer und einen zufälligen Nonce.

Was ist der Unterschied zwischen einem AS-Request und einem TGS-Request?

Ein AS-Request ist die Anforderung für ein Ticket-Granting-Ticket (TGT), während ein TGS-Request die Anforderung an den Ticket-Granting-Server ist, um ein Ticket für den Zugriff auf eine bestimmte Ressource zu erhalten.

Wie schützt der Nonce vor Replay-Angriffen?

Der Nonce ist eine zufällige Zahl, die nur einmal verwendet wird. Wenn der Server einen AS-Request mit demselben Nonce empfängt, verwirft er die Anfrage, da der Nonce nicht wiederholt werden sollte.

Was ist der Zweck der Session-Key im Kerberos-Protokoll?

Die Session-Key wird verwendet, um sicherzustellen, dass die Kommunikation zwischen dem Client und den Servern (AS und TGS) sicher ist. Sie wird für die Verschlüsselung von Nachrichten beiderseits verwendet.

Was ist der KDC-Zeitstempel?

Der KDC-Zeitstempel ist die aktuelle Zeit auf dem Key Distribution Center (KDC)-Server. Er wird verwendet, um sicherzustellen, dass die Kommunikation zeitlich gültig ist und nicht veraltet ist.

Was geschieht, wenn der Client ein Ticket-Granting-Ticket an den Ticket-Granting-Server sendet?

Der Client sendet ein Ticket-Granting-Ticket zusammen mit einem Authenticator an den TGS. Der Authenticator enthält den Namen des Clients und einen Zeitstempel und ist mit der Session-Key verschlüsselt. Der TGS kann den Authenticator entschlüsseln und stellt dann ein Ticket für die angeforderte Ressource aus.

Was ist die Bedeutung der Ticket-Gültigkeitsdauer?

Die Ticket-Gültigkeitsdauer gibt an, wie lange das Ticket für den Zugriff auf die Ressource gültig ist. Nach Ablauf dieser Zeit muss der Prozess zur Erlangung eines neuen Tickets wiederholt werden.

Welche Rolle spielt die IP-Adresse im Ticket-Granting-Ticket?

Die IP-Adresse im Ticket-Granting-Ticket identifiziert den Client, der auf die Ressource zugreifen möchte. Sie kann jedoch auch manipuliert werden, weshalb sie manchmal als unsicher angesehen wird und aus dem Ticket entfernt werden kann.

Outlines

00:00

🔐 Kerberos-Authentifizierung und Ticket-basierte Zugriffskontrolle

In diesem Absatz wird die Kerberos-Authentifizierungsmethode und der Prozess zur Ressourcenerfassung erläutert. Es wird betont, dass Kerberos die Möglichkeit bietet, ohne öffentliche Schlüsselkryptographie eine sichere Authentifizierung und das sogenannte perfekte Vorwärtsgeheimhaltung zu erreichen. Der Absatz beschreibt den Prozess der Kommunikation mit dem Ticket-Gewährungs-Server, der für den Zugriff auf Ressourcen erforderlich ist. Hierbei wird ein sogenannter Ticket benötigt, das vom Ticket-Gewährungs-Server zugewiesen wird. Der Absatz führt durch die Schritte der AS-Anfrage (Authentication Server Request), AS-Antwort (AS-Reply) und TGS-Anfrage (Ticket Granting Server Request). Es wird erklärt, wie ein Client ein Ticket erhält, indem er einen AS-Request mit seinem Namen, gewünschtem Ticket-Dauer und einem zufälligen Nonce sendet. Der Server antwortet mit einem großen Paket, der sogenannten Authentication Server Reply Package, das den gewünschten Ticket-Dauer, das Ticket selbst und einen Sitzungsschlüssel enthält, der für weitere Kommunikation zwischen dem Client und den Servern verwendet wird. Der Sitzungsschlüssel ist vor Replay-Angriffen geschützt, da er mit dem Nonce verknüpft ist.

05:07

🛡️ Schutzmechanismen im Kerberos-Protokoll

Der zweite Absatz konzentriert sich auf die Schutzmechanismen innerhalb des Kerberos-Protokolls. Es wird erklärt, wie ein Client mit einem zufälligen Nonce und einer Sitzungsschlüssel-Verschlüsselung vor Replay-Angriffen geschützt ist. Der Absatz beschreibt, wie der Authentication Server eine Antwort sendet, die den Sitzungsschlüssel, den Nonce und einen Zeitstempel enthält, der ständig wechselt und somit vor Vorhersage durch Dritte geschützt ist. Der Sitzungsschlüssel ist nur für den Client und den Ticket-Gewährungs-Server bekannt, was sicherstellt, dass nur autorisierte Benutzer auf die Ressourcen zugreifen können. Der Absatz erklärt auch, wie der Ticket-Gewährungs-Ticket die Identität des Clients, die IP-Adresse, den Sitzungsschlüssel, die Gültigkeitsdauer und einen Zeitstempel enthält, um die Gültigkeit der Anfrage zu überprüfen. Es wird auch darauf hingewiesen, dass die IP-Adresse manchmal weggelassen wird, da sie als unsicher angesehen wird und leicht manipuliert werden kann.

10:10

📅 Ticket-Lebensdauer und Authentifizierungsprozess

In diesem letzten Absatz wird die Ticket-Lebensdauer und der Prozess der Authentifizierung mit dem Ticket-Gewährungs-Server erläutert. Es wird betont, dass die Gültigkeitsdauer des Tickets, das für den Zugriff auf eine Ressource benötigt wird, von der Gültigkeitsdauer des Ticket-Gewährungs-Tickets unterschieden werden kann. Der Client kann mit einem kurzlebigen Ticket-Gewährungs-Ticket Anfragen für längere gültige Tickets stellen, um auf Ressourcen zuzugreifen. Der Absatz erklärt auch, wie der Client einen Nonce und den Namen der gewünschten Ressource in seine Anfrage aufnimmt, um einen Ticket-Gewährungs-Server-Request zu erstellen. Der Server antwortet daraufhin mit einem Ticket, das für den Zugriff auf die angeforderte Ressource verwendet wird. Der Sitzungsschlüssel, der für die Authentifizierung zwischen dem Client und dem Server verwendet wird, ist nur dem Client und dem Key Distribution Center bekannt, was die Sicherheit des Prozesses gewährleistet.

Keywords

💡Kerberos

Kerberos ist ein Sicherheitsprotokoll, das auf einem Ticket-basierten Authentifizierungsframework basiert. Es ermöglicht Benutzern und Diensten die sichere Authentifizierung bei einem zentralen Ticket-Granting-Server (TGS) ohne das Risiko der Offenlegung von Anmeldedaten. Im Video wird Kerberos als Beispiel für die Umsetzung von Netzwerksicherheit und Authentifizierung ohne die Verwendung von öffentlichen Schlüsseln behandelt.

💡Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) ist ein Sicherheitskonzept, das sicherstellt, dass zukünftige Kommunikationen, die auf heutigen Schlüsseln basieren, auch dann sicher sind, wenn diese zukünftig kompromittiert werden. Im Kontext des Videos gewährleistet PFS, dass selbst wenn jemand zukünftig Zugang zu alten Schlüsseln erhält, er keine Kommunikation entschlüsseln kann, die mit den ursprünglichen Schlüsseln verschlüsselt wurde.

💡Ticket Granting Server (TGS)

Der Ticket Granting Server ist ein zentraler Bestandteil des Kerberos-Protokolls. Er ist für die Vergabe von Tickets an Clients zuständig, die auf Ressourcen zugreifen möchten. Im Video wird erläutert, wie ein Client ein Ticket vom TGS erhält, das es ihm ermöglicht, auf angeforderte Ressourcen zuzugreifen.

💡Authentication Server (AS)

Der Authentication Server ist eine Komponente des Kerberos-Systems, die für die Authentifizierung von Clients gegenüber dem Kerberos-System zuständig ist. Im Video wird beschrieben, wie der AS-Request und AS-Reply-Prozess funktioniert, um dem Client ein Ticket Granting Ticket zu übermitteln.

💡Ticket Granting Ticket (TGT)

Das Ticket Granting Ticket ist ein von einem Authentication Server ausgestelltes Ticket, das einem Client ermöglicht, weitere Tickets für den Zugriff auf Ressourcen vom Ticket Granting Server zu erhalten. Im Video wird der Prozess beschrieben, wie ein Client ein TGT erhält und wie es später für die Anforderung von Ressourcen-Tickets verwendet wird.

💡Nonce

Ein Nonce (Number used once) ist eine zufällige Zahl, die nur einmal in einem bestimmten Kontext verwendet wird. Im Video wird erläutert, wie ein Nonce in der Authentifizierungsabfrage verwendet wird, um Replay-Angriffe zu verhindern und sicherzustellen, dass die Kommunikation sicher ist.

💡Session Key

Eine Sitzungsschlüssel ist ein kryptografischer Schlüssel, der für die Dauer einer bestimmten Sitzung verwendet wird. Im Video wird beschrieben, wie eine Sitzungsschlüssel zwischen dem Client und dem KDC (Key Distribution Center) generiert wird und wie er für die Verschlüsselung von Nachrichten verwendet wird.

💡Replay Attack

Eine Replay-Attacke ist ein Angriff, bei dem ein Angreifer eine authentifizierte Nachricht, die er abgefangen hat, erneut sendet, um die Authentizität zu behaupten. Im Video wird erläutert, wie das Konzept des Nonce dazu beiträgt, Replay-Angriffe zu verhindern.

💡IP Spoofing

IP Spoofing ist ein Angriffsmuster, bei dem ein Angreifer die IP-Adresse eines legitimen Systems imitiert, um sich als dieses System ausgeben zu können. Im Video wird darauf hingewiesen, dass IP-Adressen in Kerberos-Tickets nicht sicher sind und wie manche Implementierungen diese Informationen auslassen, um Manipulationen zu verhindern.

💡Timestamp

Ein Timestamp ist eine Zeitmarke, die verwendet wird, um die Aktualität einer Nachricht oder eines Ereignisses zu bestätigen. Im Video wird beschrieben, wie der Timestamp zusammen mit dem Nonce verwendet wird, um sicherzustellen, dass eine Nachricht nicht erneut gesendet wird und dass sie innerhalb eines bestimmten Zeitfensters gültig ist.

💡Symmetric Cryptography

Symmetrische Kryptografie ist eine Methode der Datenverschlüsselung, bei der der gleiche Schlüssel zum Verschlüsseln und Entschlüsseln von Daten verwendet wird. Im Video wird erläutert, wie symmetrische Kryptografie in Kerberos zum Schutz der Kommunikation zwischen dem Client, dem Authentication Server und dem Ticket Granting Server eingesetzt wird.

Highlights

Kerberos-Protokoll ermöglicht es, ohne öffentliche Schlüsselkryptographie auf sichere Weise auf Ressourcen zuzugreifen.

Das Konzept der perfekten Vorwärtsgeheimhaltung wird erläutert, bei der zukünftige Nachrichten nicht mit alten Geheimnissen entschlüsselt werden können.

Die Authentisierung bei Kerberos erfolgt ohne öffentliche Schlüssel, was die Komplexität verringert.

Beschreibung des Prozesses, wie ein Benutzer (Alice) eine sogenannte Ticket-Gewährung von einem Ticket-Gewährungs-Server erhält.

Ein Ticket ist ein von einem Ticket-Gewährungs-Server zugewiesener Name, der für den Zugriff auf eine Ressource benötigt wird.

Die AS-Anfrage (Authentication Server Request) enthält lediglich den Namen, die gewünschte Ticket-Dauer und einen zufälligen Nonce.

Der Nonce ist ein einmaliges, nicht wiederholtes Zufallsnummer, das für die Sicherheit des Protokolls essentiell ist.

Die Authentisierungsserverantwort (AS-Reply) enthält ein großes Paket, das den Ticket-Gewährungs-Ticket und weitere Informationen enthält.

Das Ticket-Gewährungs-Ticket ist mit dem Master-Secret des KDC (Key Distribution Center) verschlüsselt, was eine hohe Sicherheit gewährleistet.

Die Sitzungsschlüssel zwischen Alice und dem KDC sind in der AS-Antwort enthalten und für weitere Kommunikation wichtig.

Die Sitzungsschlüssel-Entschlüsselung verhindert, dass zukünftige Nachrichten mit dem Schlüssel gelesen werden können.

Die Verwendung von Nonce schützt vor Wiederholungsangriffen, indem sie sicherstellt, dass Pakete nur einmal verarbeitet werden.

Die Ticket-Gewährungs-Ticket enthält Informationen wie den Namen des Benutzers, die IP-Adresse, die Sitzungsschlüssel und weitere.

Die IP-Adresse im Ticket-Gewährungs-Ticket kann manipuliert werden, was zu Sicherheitsrisiken führen kann.

Die Authentifikatoren, die Alice an den Ticket-Gewährungs-Server sendet, sind mit der Sitzungsschlüssel verschlüsselt.

Die Ticket-Gewährungs-Server-Antwort wird in zukünftigen Abschnitten behandelt und enthält entscheidende Informationen für den Zugriff auf Ressourcen.

Die Ticket-Lebensdauer bestimmt, wie lange der Benutzer auf die Ressource zugreifen kann, bevor er das Prozedere wiederholen muss.

Transcripts

Hello and welcome back to the network security and back to Kerberos.

Today we want to look at how you can actually ask for such a resource here and how it can work that you can just do something with the login data here without leaving a encrypted network connection somehow and at the same time guarantee perfect forward secrecy.

That means no one can later start anything with the news, the long-lasting secrets are protected and so on and so forth.

Yes, how can you achieve the whole thing without public key cryptography? Well, it's actually not that hard.

Kerberos does exactly that in the end. We looked at it last time, which way you have to go and today we want to see how we get to this ticket granting server.

That means, to access the resource here, you need a so-called ticket. This ticket is therefore assigned a name from the ticket granting server.

So that the ticket granting server assigns you something, you need a so-called ticket granting ticket and we want to take a closer look at how you get there and what these requests look like.

That means, we want to take a closer look at the AS-Request, the AS-Reply and the TGS-Request. So, let's take a look at the so-called AS or Authentication Server Request for the first time.

In the end, there is nothing in it except the name, so Alice in our case, just the ticket duration, which you wish for, for example 5 minutes and some nonce, a random number.

Nonce means number only once, that means, here comes a random number that should not repeat itself. So not just sending 4, but really a random number.

If it's always the same number, then you can attack it super easily and nothing is safe anymore.

And what happens now with the server? It still doesn't know if it's really Alice. Please note that this package is super easy to fake.

A nonce can not be predicted by the authentication server. It's really random. The client doesn't know either.

The ticket duration is just a random number and the name is public. This package can also be read and sent at any time. The nonce can be changed and everything is fine.

But make sure that the whole thing is still super safe, because the following happens.

The authentication server sends this huge package back, a so-called Authentication Server Reply Package.

Of course, the name is in there first. It says the duration of the ticket as long as this ticket is valid.

It doesn't have to be as long as Alice wants it to be. It can be as long as the authentication server wants it to be.

But in the end, of course, it always tries to meet the client's desired length.

But I still took something else here so that you can see that they don't have to be the same.

Then the length of the whole package so that everyone knows how long the package is.

And then in the middle our ominous ticket granting ticket, which we will later use for the ticket granting server, you can see here in the background.

It is encrypted with the master secret of KDC. What exactly is in there, we'll take a look at it right away, don't worry.

What does that mean? It is encrypted with the master secret of KDC.

Well, that means as much as authentication server, so as I said, it's all symmetrically encrypted, so AIS.

Who has this key can decrypt it, no one else.

That means the authentication server can decrypt the thing and of course decrypt it.

He just did that, otherwise he wouldn't have been able to build it.

And the ticket granting server can decrypt it and could theoretically decrypt it again, but it doesn't.

And no one else. That means even our client who asks for something here.

This ticket is a black box for him, he has no idea what's in there.

This key is only known to the two servers here and no one else.

So, and then comes the part that no one but Alice can read now.

And the part up here, the black part, is readable by everyone.

This golden part here, or actually yellow, doesn't matter, no one but the server can read it.

And this red part can read the authentication server. Of course, it has the master secret of Alice,

but Alice herself has her own master secret.

And in there, well, only Alice can decrypt it, no one else.

In there is the session key between Alice and the KDC, that means these two servers up here for further communication.

If the session key is decrypted, then all messages that were ever transmitted on this path and encrypted with the session key are no longer readable.

That means, well, you can't do anything again if the session key is not there.

Then there is the nonce again, that's the same nonce as here.

That protects against replay attacks, that means if I just send this package to the authentication server,

then it notices, okay, same nonce, that means I'm throwing away the package.

Because this nonce, as I said, has to be number only once, meaning it only counts once, so it can't be twice.

But if I choose another nonce here, and otherwise everything is the same, because I just sniffed the name,

then I can of course send this package again.

And what happens here is, this thing here is encrypted.

That means, this new nonce that I chose, without being Alice, is encrypted here.

And I have no idea, the package looks completely different.

Also the KDC timestamp here, that's the time stamp, the current time on the server up here,

that changes constantly, of course.

That means, I can't predict this encryption here again, that means I can't know what the session key looks like here.

But Alice can decrypt it, of course, because she has her master secret.

That means, she gets the session key, she gets her nonce back, so she really knows that the authentication server sent this answer.

Could of course also be a bad person.

And she has the timestamp, that she will need later.

So, and with that she can now go a little further and run to the ticket granting server.

But let's first look at what's in the ticket granting ticket.

This ticket granting ticket is now sent to the ticket granting server.

That means, that's only readable for her. Alice has no idea what's in here.

In the end, she does have a rough idea of what's in there.

But no one but the ticket granting server can decrypt this thing here.

And that means, no one but the ticket granting server and the authentication server can change this.

That's the important thing here. No one can change this thing here without destroying the entire package.

So, what happens here is the following. The ticket granting ticket contains the name of the person who wants to log in.

Then the IP address of the client. This one is not really secure here.

Someone can of course just cheat on this.

That means, if someone could manipulate this ticket granting ticket and could also steal the session key from Alice,

then he can manipulate the IP address of the client, i.e. do IP spoofing,

and pretend that he is the client at point 12.

So, 192.168.0.12.

That means, this is sometimes left out, because you assume that it's not a security factor anyway.

I can also throw it out right away, it's no use.

Then there is of course the session key in here, so that the ticket granting server also knows

what was encrypted by Alice.

Because Alice has no possibility to write anything in here.

Alice can only encrypt things with her session key, with exactly this session key that she received.

That's why the session key has to be transferred to the ticket granting server somehow,

so that it can't be manipulated.

So, this is the same session key that Alice uses afterwards, so that they can communicate with each other,

and, well, encrypt.

Then the duration of the package, so that the ticket granting server can directly check if the thing is still valid,

or if it has expired for a long time.

And then of course the timestamp here, so that it can also check,

okay, this is the KDC timestamp, 4 minutes on it, is it still valid, yes or no.

So, wonderful.

That's how this ticket granting ticket looks inside, so to speak.

And now Alice can go and send a ticket granting server request,

by simply sending this ticket granting ticket, which we just looked at, to the ticket granting server.

So, and now she can go and say, okay, the ticket granting server has the session key,

that means I can communicate with this session key encrypted.

I can simply encrypt things with the session key here,

and the ticket granting server can decrypt it and also understand what I wrote.

And that's why there is a so-called authenticator here,

which contains the name of the client and the current timestamp also from the client.

Attention, the timestamp is unencrypted here later,

that means it has been transmitted completely in plain text.

And now this authenticator, so only name and timestamp, that's all,

is encrypted with the session key.

But the session key was more or less secretly transferred,

that means, first of all, let's take a look at this package here.

The session key was then transferred to Alice with her master key,

that means no one but Alice could decrypt this here.

And to the ticket granting server, the session key was transferred here with the master key of the key distribution center,

that means no one but the ticket granting server could read this.

That means no one but Alice and the ticket granting server and the authentication server,

which is basically part of the ticket granting server.

That means no one can really encrypt names and timestamps here,

as it is in the authenticator,

except for the client who has legally requested the package here.

So, then the timestamp itself again, so that we are really on a wavelength here,

and the ticket lifetime, which you would like to have,

for example, I would like to have a ticket for an hour,

then it is a different lifetime than the one for the ticket granting ticket.

I can, so to speak, with a ticket granting ticket that is valid for 4 minutes,

we have that here, I can request a ticket for 4 minutes.

But the ticket itself can be valid for a year, for example,

because I can communicate with the person for a year.

A year is a bit exaggerated now, but 60 minutes would be quite normal.

But also, for example, only 5 minutes, if I just want to print something,

I don't need that long.

And that's why this is actually something different here.

But I can also have a ticket granting ticket exhibited,

with which I can have some other tickets exhibited for an hour,

because I have to print something on 100 different printers.

And then I only need 5 minutes each.

That means the ticket lifetime is actually how long I have access to the resource afterwards,

before I have to repeat the process here.

So, and then just put a nonce in there,

any random number, as I said,

that's against replay attacks, we just looked at that,

and then the resource name I want to have access to.

That means, for example, in our case, Bob, or printer XY or something.

And then the ticket granting server answers, and we'll take a look at that next time.

It was important here, the authenticator is encrypted with the session key,

which can only be found in the client and in the key distribution center up here.

No one else can have it.

Good, that's it from my side.

Thank you for your attention and we'll see you next time.

See you, ciao!