[Kerberos] Kerberos Authentication Explained | A deep dive 번역

Kerberos

Source

https://www.youtube.com/watch?v=5N242XcKAsM 

Kerberos Authentication Explained | A deep dive

 

So you want to connect to an application over an insecure network, but you're a wee bit paranoid.

안전하지 않은 네트워크를 통해 애플리케이션에 연결하고 싶지만 편집증에 시달리고 있습니다.

 

Someone may be listening in.

누군가 엿듣고 있을지도 모르기 때문입니다.

 

How do you solve this problem? One possible solution is a protocol designed to provide secure authentication to services over an insecure network.

이 문제를 어떻게 해결할 수 있을까요? 한 가지 가능한 해결책은 안전하지 않은 네트워크 안에 있는 서비스에 보안 인증을 제공하도록 설계된 프로토콜입니다.

 

Passwords are never sent across the network.

비밀번호는 네트워크를 통해 전송되지 않습니다.

 

Encryption keys are never directly exchanged.

암호화 키는 직접 교환되지 않습니다.

 

You and the application can mutually authenticate each other.

사용자와 애플리케이션이 서로를 인증할 수 있습니다.

 

Many organizations use it as the basis for single sign-on.

많은 조직에서 single-sign-on의 기반으로 사용합니다.

 

What wonder protocol can do all of this for us? Kerberos.

어떤 놀라운 프로토콜이 이 모든 기능을 수행할 수 있을까요? 바로 케르베로스입니다.

 

Hey, I'm Rob Witcher.

안녕하세요, Rob Witcher입니다.

 

In today's episode, we're going to dig into the details of Kerberos to understand how it works.

오늘 에피소드에서는 Kerberos의 작동 원리를 이해하기 위해 자세히 살펴보겠습니다.

 

A mildly interesting bit of trivia behind the naming of Kerberos.

케르베로스의 이름 뒤에 숨겨진 약간 흥미로운 상식이 있습니다.

 

It comes from Greek mythology.

케르베로스는 그리스 신화에서 유래했습니다.

 

The Kerberos protocol guards access to applications and so was named after the three-headed dog, Cerberus, the Hound of Hades, who guards the gates to the underworld.

케르베로스 프로토콜은 애플리케이션에 대한 액세스를 보호하기 때문에 지하 세계로 통하는 문을 지키는 세 개의 머리를 가진 개, 하데스의 사냥개 케르베로스의 이름에서 유래되었습니다.

 

Unsurprisingly, I couldn't find any good stock footage of a three-headed dog, but these three business dogs are pretty darn adorable.

당연히 머리가 셋 달린 개가 등장하는 스톡 영상을 찾을 수 없었지만, 이 세 마리의 비즈니스 개는 꽤나 사랑스럽습니다.

 

Let's start our tour of Kerberos with some terminology.

몇 가지 용어로 케르베로스 투어를 시작하겠습니다.

 

A Kerberos realm is the domain, the group of systems over which Kerberos has the authority to authenticate a user to a service.

Kerberos realm은 사용자를 서비스에 인증할 수 있는 권한이 있는 시스템 그룹 도메인을 말합니다.

 

You can have multiple realms and you can interconnect them.

여러 개의 realm을 가질 수 있으며 서로 연결할 수 있습니다.

 

Within a realm, you have principles.

realm 내에는 principal들이 있습니다.

 

A principal is a unique identity, either a user or a service, an application.

principal은 사용자 또는 서비스, 애플리케이션과 같은 고유한 ID입니다.

 

A client is a process that accesses a service on behalf of a user.

클라이언트는 사용자를 대신하여 서비스에 액세스하는 프로세스입니다.

 

You can have multiple clients or users within a realm.

한 realm 내에 여러 클라이언트 또는 사용자를 보유할 수 있습니다.

 

Essentially, these are our users that want to access stuff.

기본적으로 이들은 어딘가에 액세스하려는 사용자입니다.

 

A service is a resource provided to a client, for example, a file server or an application that a user wants to access.

서비스는 사용자가 액세스하려는 파일 서버나 애플리케이션과 같이 클라이언트에 제공되는 리소스입니다.

 

You can have multiple services that clients can access.

클라이언트가 액세스할 수 있는 서비스는 여러 개가 있을 수 있습니다.

 

The key distribution center, the KDC, is the heart of Kerberos.

키 배포 센터인 KDC는 Kerberos의 핵심입니다.

 

The KDC supplies tickets and generates temporary session keys that allow a user to securely authenticate to a service.

KDC는 티켓을 제공하고 사용자가 서비스에 안전하게 인증할 수 있는 임시 세션 키를 생성합니다.

 

The KDC stores all the secret symmetric keys for users and services.

KDC에는 사용자와 서비스에 대한 모든 비밀 대칭 키가 저장됩니다.

 

There are two servers within the KDC, the authentication server and the ticket-granting server.

KDC에는 인증 서버와 티켓 부여 서버라는 두 개의 서버가 있습니다.

 

The authentication server confirms that a known user is making an access request and issues ticket-granting tickets.

인증 서버는 알려진 사용자가 액세스 요청을 하고 있는지 확인하고 티켓 부여 티켓(ticket-granting tickets)을 발급합니다.

 

The ticket granting server confirms that a user is making an access request to a known service and issues service tickets.

티켓 부여 서버는 사용자가 알려진 서비스에 대한 액세스 요청을 하고 있는지 확인하고 서비스 티켓(service tickets)을 발급합니다.

 

There are a ton of messages passed back and forth between user, authentication server, ticket-granting server, and the service.

사용자, 인증 서버, 티켓 부여 서버, 서비스 간에 수많은 메시지가 오고 갑니다.

 

At least two messages are sent at almost every step.

거의 모든 단계에서 최소 두 개의 메시지가 전송됩니다.

 

Some messages are in plain text and some are encrypted with a symmetric key.

일부 메시지는 일반 텍스트로 되어 있고 일부는 대칭 키로 암호화되어 있습니다.

 

There are two important types of messages worth highlighting.

두 가지 중요한 유형의 메시지가 있습니다.

 

Authenticators are a record containing information that can be shown to have been recently generated by a user.

인증자는 사용자가 최근에 생성한 것으로 표시될 수 있는 정보가 포함된 레코드입니다.

 

Authenticators are information that can be shown to have been recently generated using the session key known only to the client and the server.

인증자는 클라이언트와 서버만 알고 있는 세션 키를 사용하여 최근에 생성된 것으로 표시할 수 있는 정보입니다.

 

Essentially, authenticators allow the user to authenticate to the service and the service to authenticate to the user.

기본적으로 인증자는 사용자가 서비스에 인증하고 서비스가 사용자를 인증할 수 있도록 합니다.

 

Mutual authentication.

상호 인증.

 

And tickets.

그리고 티켓.

 

Tickets contain most of the information that needs to be passed.

티켓에는 전달해야 하는 대부분의 정보가 포함되어 있습니다.

 

The client's identity, service ID, session keys, time stamps, time to live, etc.

클라이언트의 신원, 서비스 ID, 세션 키, 타임 스탬프, 사용 시간 등이 포함됩니다.

 

All encrypted with the user's secret key.

모두 사용자의 비밀 키로 암호화됩니다.

 

Now let's look at a high level overview of the communications that occur for a user to gain access to a service.

이제 사용자가 서비스에 액세스하기 위해 발생하는 통신에 대한 높은 수준의 개요를 살펴보겠습니다.

 

We start with the user sending an unencrypted message to the authentication server saying, hey, I'd like to access some service.

먼저 사용자가 인증 서버에 "어떤 서비스에 액세스하고 싶습니다"라는 암호화되지 않은 메시지를 보냅니다.

 

The authentication service validates the request is coming from a known user and generates a ticket granting ticket, the TGT.

인증 서비스는 요청이 알려진 사용자로부터 온 것인지 확인하고 티켓 부여 티켓인 TGT를 생성합니다.

 

The TGT is sent back to the user along with another message encrypted with the users secret key.

TGT는 사용자의 비밀 키로 암호화된 다른 메시지와 함께 사용자에게 다시 전송됩니다.

 

The user decrypts the message with their secret key and then creates a couple new messages and sends the new messages along with the TGT on to the ticket granting service. 

사용자는 비밀 키로 메시지를 해독한 다음 몇 개의 새 메시지를 작성하고 새 메시지를 TGT와 함께 티켓 부여 서비스로 보냅니다.

 

The ticket granting service decrypts the ticket granting ticket, performs some validation, and generates a service ticket.

티켓 부여 서비스는 티켓 부여 티켓을 해독하고 몇 가지 유효성 검사를 수행한 후 서비스 티켓을 생성합니다.

 

The service ticket along with another message is sent back to the user.

서비스 티켓은 다른 메시지와 함께 사용자에게 다시 전송됩니다.

 

The user decrypts the message, creates an authenticator message, and sends the user authenticator and the service ticket to the service.

사용자는 메시지를 해독하고 인증자 메시지를 만든 다음 사용자 인증자와 서비스 티켓을 서비스에 보냅니다.

 

The service does its own decryption, validation, and creates its own final authenticator message.

서비스는 자체적으로 복호화, 유효성 검사를 수행하고 자체 최종 인증자 메시지를 만듭니다.

 

This final authenticator message is sent back to the user.

이 최종 인증자 메시지는 사용자에게 다시 전송됩니다.

 

All of these messages allow the user and the server to mutually authenticate each other and securely distribute a symmetric service session key, which allows the user and the service to communicate authentication information securely.

이러한 모든 메시지를 통해 사용자와 서버는 서로를 상호 인증하고 대칭적인 서비스 세션 키를 안전하게 배포하여 사용자와 서비스가 인증 정보를 안전하게 통신할 수 있습니다.

 

For the purposes of the CISSP exam, that's probably about the right amount of detail to know, but for fun, let's look at each of these steps and message exchanges in excruciating detail.

CISSP 시험의 목적상 이 정도만 알면 충분할 것 같지만, 재미 삼아 각 단계와 메시지 교환에 대해 자세히 살펴보겠습니다.

 

We'll start at the very beginning with the first unencrypted message that the user is going to send to the authentication server.

가장 먼저 사용자가 인증 서버로 보낼 첫 번째 암호화되지 않은 메시지부터 시작하겠습니다.

 

The message contains the user's ID.

이 메시지에는 사용자의 ID가 포함됩니다.

 

We'll use Rob as the ID.

여기서는 Rob을 ID로 사용하겠습니다.

 

The ID of the service that the user wants to access.

사용자가 액세스하려는 서비스의 ID입니다.

 

We'll use a CRM application as an example.

CRM 애플리케이션을 예로 들어 보겠습니다.

 

The user's IP address.

사용자의 IP 주소입니다.

 

This can be a single IP address, multiple IP addresses, or even null depending on how Kerberos has been configured.

Kerberos가 구성된 방식에 따라 단일 IP 주소, 여러 IP 주소 또는 null일 수도 있습니다.

 

And the requested lifetime of the ticket granting ticket.

그리고 티켓 부여 티켓의 요청된 수명입니다.

 

Users would typically like a ticket that has an infinite lifetime so they never have to authenticate again, but that's not a super great idea from a security perspective.

사용자는 일반적으로 다시 인증할 필요가 없는 무한한 수명의 티켓을 원하지만 보안 관점에서 볼 때 이는 그리 좋은 생각이 아닙니다.

 

So Kerberos can just ignore what the user asks for.

따라서 Kerberos는 사용자가 요청하는 것을 무시할 수 있습니다.

 

Once the user has their first message ready, they send it over to the authentication server.

사용자가 첫 번째 메시지를 준비하면 인증 서버로 전송합니다.

 

The first thing the authentication server does is look at the user ID in the message.

인증 서버가 가장 먼저 하는 일은 메시지에서 사용자 ID를 확인하는 것입니다.

 

The authentication server being part of the KDC has a list of all the users and their secret keys.

KDC의 일부인 인증 서버는 모든 사용자와 비밀 키의 목록을 가지고 있습니다.

 

And so it checks that the user ID in the message is in the list of users in the KDC.

따라서 메시지의 사용자 ID가 KDC의 사용자 목록에 있는지 확인합니다.

 

And if so, grabs a copy of that user's secret client key.

그렇다면 해당 사용자의 비밀 클라이언트 키의 사본을 가져옵니다.

 

We'll see where that's used in a moment.

이것이 어디에 사용되는지 잠시 후에 살펴보겠습니다.

 

The authentication server now needs to create some messages to send back to the user.

이제 인증 서버는 사용자에게 다시 보낼 몇 가지 메시지를 만들어야 합니다.

 

The first message it creates contains the ID of the ticket granting server, the timestamp the message was created, and the message lifetime.

인증 서버가 만드는 첫 번째 메시지에는 티켓 부여 서버의 ID, 메시지가 만들어진 타임스탬프 및 메시지 수명이 포함됩니다.

 

The second message is the ticket granting ticket.

두 번째 메시지는 티켓 부여 티켓입니다.

 

It contains the user's ID, the ticket granting server's ID, a timestamp, the user's IP address, and the lifetime of the ticket granting ticket.

여기에는 사용자의 ID, 티켓 부여 서버의 ID, 타임스탬프, 사용자의 IP 주소 및 티켓 부여 티켓의 수명이 포함됩니다.

 

It could be what the user requested or a different value depending on how Kerberos has been configured.

이 값은 사용자가 요청한 값일 수도 있고 Kerberos가 구성된 방식에 따라 다른 값일 수도 있습니다.

 

The final piece that the authentication server adds to each message is a ticket granting server session key.

인증 서버가 각 메시지에 추가하는 마지막 부분은 티켓 부여 서버 세션 키입니다.

 

This is just a randomly generated symmetric key.

이 키는 무작위로 생성된 대칭 키입니다.

 

Each message is then encrypted.

그런 다음 각 메시지가 암호화됩니다.

 

The first message is encrypted with the user's secret key, and the second message the TGT is encrypted with the ticket granting server's secret key.

첫 번째 메시지는 사용자의 비밀 키로 암호화되고, 두 번째 메시지는 TGT가 티켓 부여 서버의 비밀 키로 암호화됩니다.

 

These two encrypted messages are now sent from the authentication server to the user.

이제 이 두 개의 암호화된 메시지가 인증 서버에서 사용자에게 전송됩니다.

 

The user needs to decrypt the first message.

사용자는 첫 번째 메시지의 암호를 해독해야 합니다.

 

To do so, the user generates their secret key.

이를 위해 사용자는 비밀 키를 생성합니다.

 

They do so by entering their password.

비밀번호를 입력하여 비밀 키를 생성합니다.

 

Kerberos then adds a salt to the password and a key version number, the KVNO.

그러면 Kerberos는 비밀번호에 솔트를 추가하고 키 버전 번호인 KVNO를 추가합니다.

 

The salt is usually the user's username at realm name.

솔트는 일반적으로 영역 이름에서 사용자의 사용자 이름입니다.

 

The KVNO is useful when long-lived keys are used.

KVNO는 수명이 긴 키를 사용할 때 유용합니다.

 

The user's salted password is run through a hashing algorithm, specifically string to key, to generate the user's secret key.

사용자의 솔트된 비밀번호는 해싱 알고리즘(특히 문자열을 키로 변환하는 알고리즘)을 통해 실행되어 사용자의 비밀 키를 생성합니다.

 

And this key is used to decrypt the first message.

그리고 이 키는 첫 번째 메시지를 해독하는 데 사용됩니다.

 

This is a step where the user's password is validated, because if the user entered the wrong password, then the user's secret key that was generated would be the wrong key, and it wouldn't decrypt the message.

사용자가 잘못된 비밀번호를 입력하면 생성된 사용자의 비밀 키가 잘못된 키가 되어 메시지를 해독하지 못하기 때문에 이 단계는 사용자의 비밀번호를 검증하는 단계입니다.

 

So presuming the user has entered the correct password and the message is decrypted, the user now has access to the ticket granting server's ID and the TGS session key.

따라서 사용자가 올바른 비밀번호를 입력하고 메시지가 해독되었다고 가정하면 사용자는 이제 티켓 부여 서버의 ID 및 TGS 세션 키에 액세스할 수 있습니다.

 

Note that the user cannot decrypt the ticket granting ticket, because the user doesn't have the TGS's secret key.

사용자는 TGS의 비밀 키가 없으므로 티켓 부여 티켓의 암호를 해독할 수 없다는 점에 유의하세요.

 

The user now creates two new messages.

이제 사용자가 두 개의 새 메시지를 만듭니다.

 

The first is a simple plaintext message that indicates which service the user wants to access and the requested lifetime for the service ticket.

첫 번째 메시지는 사용자가 액세스하려는 서비스와 서비스 티켓의 요청된 수명을 나타내는 간단한 일반 텍스트 메시지입니다.

 

The second message is the user authenticator, which contains the user ID and the timestamp of when the message was created.

두 번째 메시지는 사용자 ID와 메시지가 생성된 시점의 타임스탬프가 포함된 사용자 인증자입니다.

 

The user authenticator message is encrypted with the TGS session key.

사용자 인증자 메시지는 TGS 세션 키로 암호화됩니다.

 

Once the user has these new messages ready, they send these new messages along with the still encrypted ticket granting ticket over to the ticket granting server.

사용자가 이러한 새 메시지를 준비하면 아직 암호화된 티켓 부여 티켓과 함께 이러한 새 메시지를 티켓 부여 서버로 보냅니다.

 

The ticket granting server now has a bunch of work to do.

이제 티켓 부여 서버가 해야 할 일이 많습니다.

 

It starts by looking at the service ID contained in the unencrypted message and checks to see if the service ID in the message is in the list of services in the KDC.

먼저 암호화되지 않은 메시지에 포함된 서비스 ID를 살펴보고 메시지에 포함된 서비스 ID가 KDC의 서비스 목록에 있는지 확인합니다.

 

If the service is in the list, then the TGS grabs a copy of the service secret service key.

서비스가 목록에 있으면 TGS는 서비스 비밀 서비스 키의 사본을 가져옵니다.

 

That's a mouthful.

정말 어렵네요.

 

And we'll see where that is used in a moment.

이 키가 어디에 사용되는지 잠시 후에 살펴보겠습니다.

 

Okay, back to the messages that the TGS received from the user.

다시 TGS가 사용자로부터 받은 메시지로 돌아가 보겠습니다.

 

The TGS decrypts the ticket granting ticket with the TGS's secret key.

TGS는 TGS의 비밀 키로 티켓 부여 티켓을 복호화합니다.

 

Contained within the ticket granting ticket is the TGS session key and the TGS can now use this session key to decrypt the user authenticator message from the user.

티켓 부여 티켓에는 TGS 세션 키가 포함되어 있으며, TGS는 이제 이 세션 키를 사용하여 사용자로부터 받은 사용자 인증 메시지를 해독할 수 있습니다.

 

Now that both the TGT and the authenticator message have been decrypted, the TGS starts to validate the data contained within.

이제 TGT와 인증자 메시지가 모두 해독되었으므로 TGS는 그 안에 포함된 데이터의 유효성을 검사하기 시작합니다.

 

The TGS first makes sure that the user ID in the TGT and the authenticator match.

TGS는 먼저 TGT의 사용자 ID와 인증자가 일치하는지 확인합니다.

 

Compares the timestamps.

타임스탬프를 비교합니다.

 

Typically Kerberos is configured to tolerate up to a two minute difference between timestamps.

일반적으로 Kerberos는 타임스탬프 간의 최대 2분 차이를 허용하도록 구성됩니다.

 

Compares the IP address in the TGT to the IP address of the user it received the messages from.

TGT의 IP 주소와 메시지를 받은 사용자의 IP 주소를 비교합니다.

 

This assumes an IP address has been set.

여기서는 IP 주소가 설정되어 있다고 가정합니다.

 

This can be null.

이 값은 null일 수 있습니다.

 

Checks that the ticket granting ticket has not expired.

티켓 부여 티켓이 만료되지 않았는지 확인합니다.

 

If everything is copacetic, then the TGS performs one more important step.

모든 것이 정상이라면 TGS는 한 가지 중요한 단계를 더 수행합니다.

 

The TGS maintains a cache of recently received authenticators from users.

TGS는 사용자로부터 최근에 받은 인증서의 캐시를 유지합니다.

 

The TGS will check its cache to ensure the authenticator it just received is not already in the cache.

TGS는 캐시를 확인하여 방금 받은 인증서가 이미 캐시에 없는지 확인합니다.

 

This check provides replay protection.

이 확인은 리플레이 보호를 제공합니다.

 

If the authenticator is not already in the cache then the TGS will add it.

인증서가 아직 캐시에 없는 경우 TGS가 인증서를 추가합니다.

 

The TGS now moves on to creating its own messages to the user.

이제 TGS는 사용자에게 보내는 자체 메시지를 생성합니다.

 

The first message contains the service ID of the service the user wants to access, the timestamp of the message, and the lifetime of the message.

첫 번째 메시지에는 사용자가 액세스하려는 서비스의 서비스 ID, 메시지의 타임스탬프, 메시지의 수명이 포함됩니다.

 

The second message is the service ticket.

두 번째 메시지는 서비스 티켓입니다.

 

It contains the user ID, the service ID of the service the user wants to access, the timestamp of the message, the user's IP address, and the lifetime of the service ticket.

여기에는 사용자 ID, 사용자가 액세스하려는 서비스의 서비스 ID, 메시지의 타임스탬프, 사용자의 IP 주소 및 서비스 티켓의 수명이 포함됩니다.

 

The TGS then generates a random symmetric service session key and adds this symmetric key to both messages.

그런 다음 TGS는 임의의 대칭 서비스 세션 키를 생성하고 이 대칭 키를 두 메시지에 모두 추가합니다.

 

And the final step the TGS performs before sending the messages is encrypting them.

그리고 TGS가 메시지를 보내기 전에 수행하는 마지막 단계는 메시지를 암호화하는 것입니다.

 

The first message is encrypted with the TGS session key and the service ticket is encrypted with the service secret key.

첫 번째 메시지는 TGS 세션 키로 암호화되고 서비스 티켓은 서비스 비밀 키로 암호화됩니다.

 

These two messages are now sent to the user and as you might expect the user now has some work to do.

이제 이 두 개의 메시지가 사용자에게 전송되며 예상대로 사용자는 이제 몇 가지 작업을 해야 합니다.

 

The first message is encrypted with the TGS session key and as you may or may not recall at this point we've already gone through a lot of messages the user received the TGS session key from the authentication server.

첫 번째 메시지는 TGS 세션 키로 암호화되어 있으며, 이 시점에서 기억하실 수도 있고 기억하지 못하실 수도 있겠지만 이미 사용자가 인증 서버에서 TGS 세션 키를 받은 많은 메시지를 거쳤습니다.

 

So the user decrypts the message with its TGS session key.

따라서 사용자는 TGS 세션 키로 메시지를 복호화합니다.

 

The user can now read the contents of this message and importantly now has a copy of the service session key.

이제 사용자는 이 메시지의 내용을 읽을 수 있으며, 중요한 것은 이제 서비스 세션 키의 복사본을 갖게 되었다는 것입니다.

 

The user creates a new authenticator message containing the user's ID and a timestamp and encrypts this new authenticator with the service session key.

사용자는 사용자의 ID와 타임스탬프가 포함된 새 인증자 메시지를 생성하고 이 새 인증자를 서비스 세션 키로 암호화합니다.

 

Note the user cannot decrypt the service ticket as it was encrypted with the service's secret key.

서비스 티켓은 서비스의 비밀 키로 암호화되었으므로 사용자가 해독할 수 없다는 점에 유의하세요.

 

So the user simply forwards the service ticket along with the newly created authenticator message to the service.

따라서 사용자는 새로 생성된 인증자 메시지와 함께 서비스 티켓을 서비스에 전달하기만 하면 됩니다.

 

It's now finally the service's turn to do some work and this is going to look very similar to all the steps the ticket granting service just went through.

이제 드디어 서비스가 작업을 수행할 차례이며, 이는 티켓 부여 서비스가 방금 수행한 모든 단계와 매우 유사하게 보일 것입니다.

 

First the service decrypts the service ticket with its secret key.

먼저 서비스에서 비밀 키로 서비스 티켓을 복호화합니다.

 

This gives the service access to the service session key which the service uses to decrypt the user authenticator message.

이렇게 하면 서비스가 사용자 인증자 메시지를 해독하는 데 사용하는 서비스 세션 키에 액세스할 수 있습니다.

 

Now that both the service ticket and authenticator messages have been decrypted the service starts to validate the data contained within.

이제 서비스 티켓과 인증자 메시지가 모두 해독되었으므로 서비스는 그 안에 포함된 데이터의 유효성을 검사하기 시작합니다.

 

The service first makes sure that the user ID in the service ticket and the authenticator match, compares the timestamps and as noted before typically a difference of less than two minutes is tolerated, compares the IP address in the service ticket to the IP address of the user it received the messages from and checks to see that the service ticket has not expired.

먼저 서비스 티켓의 사용자 ID와 인증자가 일치하는지 확인하고, 타임스탬프를 비교하며, 앞서 언급한 대로 일반적으로 2분 미만의 차이는 허용되며, 서비스 티켓의 IP 주소와 메시지를 수신한 사용자의 IP 주소를 비교하고, 서비스 티켓이 만료되지 않았는지 확인합니다.

 

If everything looks good then the service checks its cache.

모든 것이 정상으로 보이면 서비스에서 캐시를 확인합니다.

 

Just like the TGS the service maintains a cache of recently received authenticators from users.

TGS와 마찬가지로 서비스도 사용자로부터 최근에 받은 인증서의 캐시를 유지합니다.

 

The service will check its cache to ensure the authenticator it just received is not already in the cache.

서비스에서 캐시를 확인하여 방금 받은 인증서가 이미 캐시에 없는지 확인합니다.

 

This check again provides replay protection.

이 확인은 다시 리플레이 보호를 제공합니다.

 

If the user authenticator is not already in the cache then the service will add it.

사용자 인증서가 아직 캐시에 없는 경우 서비스가 인증서를 추가합니다.

 

The service now needs to create its own authenticator message which it will send to the user.

이제 서비스는 사용자에게 보낼 자체 인증자 메시지를 생성해야 합니다.

 

Similar to a user authenticator message the service authenticator includes the service's ID and timestamp.

사용자 인증자 메시지와 마찬가지로 서비스 인증자에는 서비스의 ID와 타임스탬프가 포함됩니다.

 

This authenticator is encrypted with the service session key and this service authenticator message is sent to the user.

이 인증자는 서비스 세션 키로 암호화되며 이 서비스 인증자 메시지가 사용자에게 전송됩니다.

 

The user now needs to look at this message.

이제 사용자는 이 메시지를 확인해야 합니다.

 

It was encrypted with the symmetric service session key therefore it will decrypt with the same symmetric key and recall the user was sent this service session key by the TGS.

대칭 서비스 세션 키로 암호화되었으므로 동일한 대칭 키로 복호화하여 사용자에게 이 서비스 세션 키가 TGS에 의해 전송되었음을 기억할 것입니다.

 

The user will now verify that the service name contained within the authenticator is the service the user was expecting to talk to thus completing the mutual authentication.

이제 사용자는 인증자에 포함된 서비스 이름이 사용자가 대화할 것으로 예상했던 서비스인지 확인하여 상호 인증을 완료합니다.

 

The user will also look at the timestamp to make sure that the authenticator was created within the last couple of minutes and just like the TGS and the service the user also maintains its own cache.

또한 사용자는 타임스탬프를 확인하여 인증자가 지난 몇 분 이내에 생성되었는지 확인하며, TGS 및 서비스와 마찬가지로 사용자도 자체 캐시를 유지합니다.

 

Since the user has mutually authenticated the service it will cache a copy of the encrypted service ticket for future use.

사용자가 서비스를 상호 인증했으므로 나중에 사용할 수 있도록 암호화된 서비스 티켓의 사본을 캐시에 저장합니다.

 

And there you have a walkthrough of how a flurry of messages are sent by the Kerberos protocol to securely authenticate a user to a service over an insecure network.

이제 안전하지 않은 네트워크에서 사용자를 서비스에 안전하게 인증하기 위해 Kerberos 프로토콜이 수많은 메시지를 전송하는 방법을 살펴보았습니다.

 

Before we end this video here are a few more mildly interesting tidbits about Kerberos.

이 동영상을 마치기 전에 Kerberos에 대한 몇 가지 흥미로운 정보를 더 알려드리겠습니다.

 

Kerberos is a pervasively used protocol for enabling single sign-on capabilities and one of the big reasons for this is that Kerberos has been built into Windows for over 20 years since Windows 2000 as the default authentication package.

Kerberos는 싱글 사인온 기능을 구현하는 데 널리 사용되는 프로토콜이며, 그 큰 이유 중 하나는 Windows 2000부터 20년 넘게 Windows에 기본 인증 패키지로 내장되어 왔기 때문입니다.

 

Kerberos is also natively integrated or supported by a raft of other major operating systems including many flavors of Linux and Unix, AIX and many others.

또한 Kerberos는 Linux 및 Unix, AIX 등 다양한 주요 운영 체제에서 기본적으로 통합되거나 지원됩니다.

 

There are currently two major versions of Kerberos widely deployed today.

현재 널리 배포되는 Kerberos는 크게 두 가지 버전이 있습니다.

 

Version 4 was published all the way back in the late 80s and has a major security limitation.

버전 4는 80년대 후반에 발표된 버전으로 보안에 큰 제약이 있습니다.

 

It only supports DES, the data encryption standard as the encryption algorithm it uses.

이 버전은 사용하는 암호화 알고리즘으로 데이터 암호화 표준인 DES만 지원합니다.

 

DES only supports a 56-bit key which is nowhere near good enough in today's world.

DES는 56비트 키만 지원하는데, 이는 오늘날에는 충분하지 않습니다.

 

Version 5 is no spring chicken either as it was first published in 1993 with a revision in 2005.

버전 5는 1993년에 처음 발표되었고 2005년에 개정되었기 때문에 최신 버전도 아닙니다.

 

One of the significant security enhancements in version 5 is that it now supports many types of encryption and typically the advanced encryption standard AES is used as the encryption algorithm.

버전 5의 중요한 보안 개선 사항 중 하나는 이제 다양한 유형의 암호화를 지원하며 일반적으로 고급 암호화 표준인 AES가 암호화 알고리즘으로 사용된다는 것입니다.

 

AES is an excellent algorithm in today's world.

AES는 오늘날의 세계에서 탁월한 알고리즘입니다.

 

Another significant limitation of both version 4 and version 5 of Kerberos is that it only supports symmetric cryptography.

Kerberos 버전 4와 버전 5의 또 다른 중요한 한계는 대칭 암호화만 지원한다는 것입니다.

 

This leads to major key scaling and distribution problems especially in a large realm with hundreds or even thousands of systems.

이는 특히 수백 또는 수천 개의 시스템이 있는 대규모 영역에서 주요 키 확장 및 배포 문제로 이어집니다.

 

The number of keys required grows rapidly and it can be very challenging to securely distribute all these keys to the services and the KDC.

필요한 키의 수가 급격히 증가하고 이러한 모든 키를 서비스 및 KDC에 안전하게 배포하는 것은 매우 어려울 수 있습니다.

 

There are configurations and implementations of Kerberos out there that have been made to work with symmetric or public key cryptography to solve the symmetric key problems I just spoke of but this is not the default standard version of Kerberos that is natively supported in many OSs and applications.

방금 말씀드린 대칭 키 문제를 해결하기 위해 대칭 키 암호화 또는 공개 키 암호화와 함께 작동하도록 만들어진 Kerberos의 구성 및 구현이 있지만 이는 많은 OS 및 애플리케이션에서 기본적으로 지원되는 기본 표준 버전이 아닙니다.

 

And that concludes our whirlwind tour of Kerberos.

이것으로 케르베로스 소개를 마치겠습니다.

 

Thanks very much for watching.

시청해 주셔서 감사합니다.

 

I hope you found this episode informative.

이 에피소드가 유익하셨기를 바랍니다.

 

If you like this video you can hit the like button and if you want to be notified when we release future videos you can subscribe and click the bell icon.

이 영상이 마음에 드셨다면 좋아요 버튼을 눌러 주시고, 향후 영상이 공개될 때 알림을 받고 싶으시다면 구독을 신청하고 종 아이콘을 클릭하세요.

 

Let me know what you think in the comments and let me know what topics you want me to cover in the future.

댓글로 여러분의 생각을 알려주시고 앞으로 어떤 주제를 다루었으면 좋겠는지 알려주세요.

 

Cheers!

건배!