7.2.2 Пример работы протокола

Опишем пример простой транзакции Kerberos между двумя абонентами безопасности в данной среде. Для наглядности предположим, что на одной клиентской станции работает пользователь по имени Алиса, и она хочет получить доступ к серверу по имени Боб.

1. В среде Kerberos процесс аутентификации начинается с входа в систему. Алиса вводит на клиентской станции свое имя пользователя и пароль.

2. Pабочая станция посылает пользовательское имя Алисы в центр распределения ключей. Там содержится главная база данных уникальных, долгосрочных ключей всех участников сеансов связи данной зоны.

3. KDC ищет главный ключ Алисы (KA), который он определяет на основании ее пароля.

4. KDC создает сеансовый ключ (SA), которым будет пользоваться совместно с Алисой, и «билет на выдачу билета» (Ticket-Granting Ticket, TGT). Билет TGT включает вторую копию сеансового ключа (SA), имя пользователя, введенное Алисой, и срок действия. KDC шифрует этот билет своим собственным главным ключом (KKDC), который известен только KDC.

5. KDC шифрует всю эту информацию с помощью главного ключа Алисы (KA) и возвращает полученный результат на ее рабочую станцию.

6. Клиентская станция, получив сообщение, которое выглядит как беспорядочный набор случайных битов, применяет к паролю Алисы однонаправленную хэш-функцию, преобразующую пароль в главный ключ Алисы (KA). С его помощью станция расшифровывает полученный пакет и становится обладателем сеансового ключа (совместно с KDC) и билета TGT. Она может «забыть» главный ключ Алисы — для общения с KDC ей будет достаточно сеансового ключа (SA) и TGT.

Пусть теперь Алиса пытается получить доступ к Бобу.

1. Вместо того чтобы установить с ним прямой контакт, станция Алисы обращается в KDC. При этом она передает билет TGT, запрос на доступ к Бобу и порцию данных под названием «аутентификатор» — специальную отметку времени. Аутентификатор шифруется с помощью сеансового ключа, который является общим для Алисы и KDC (SA).

2. KDC расшифровывает TGT, используя свой главный ключ (KKDC). Как вы помните, в билете TGT содержится пользовательское имя Алисы и копия общего сеансового ключа (SA). KDC применяет этот сеансовый ключ (SA) для расшифровки аутентификатора и поэтому может быть уверен, что данный запрос действительно поступил от Алисы, потому что только Алиса пользуется соответствующим общим сеансовым ключом (SA).

3. KDC создает два билета — один для Алисы и один для Боба. Каждый билет содержит важную информацию, в том числе имя абонента безопасности, запросившего услугу, имя получателя запроса, время создания билета и срок его действия. Кроме того, в оба билета вносится новый ключ (KAB), который будет использоваться совместно Алисой и Бобом.

4. KDC шифрует билет Боба, используя его главный ключ (KB). Затем билет Боба вкладывается в билет Алисы, где наряду с прочими данными также содержится новый ключ (KAB): KDC шифрует весь этот массив общим с Алисой сеансовым ключом (SA), и посылает результат Алисе.

5. Получив билет, Алиса расшифровывает его с помощью сеансового ключа (SA). Таким образом, у нее оказывается новый сеансовый ключ (KAB) и билет Боба (который она не может прочитать). Затем Алиса расшифровывает аутентификатор (отметку о времени) с помощью нового ключа (KAB) и отправляет Бобу аутентификатор вместе с его билетом.

6. Получив все это, Боб сначала расшифровывает собственный билет, используя свой главный ключ (KB). Это открывает доступ к новому сеансовому ключу (KAB), который позволит расшифровать аутентификатор Алисы.

Теперь и у Алисы, и у Боба есть новый ключ (KAB). Боб может не сомневаться, что Алиса — именно та, за которую себя выдает, так как она зашифровала аутентификатор с помощью этого ключа (KAB). Если у Боба возникнет необходимость ответить Алисе, он воспользуется новым ключом (KAB). Алиса будет знать, что Боб — это именно Боб, и никто другой, потому что он мог получить новый ключ (KAB) только с помощью своего главного ключа (KAB).

Аналогичным образом Алиса может аутентифицировать себя при обращении к другим участникам. Для каждого запроса на установление связи KDC создаст уникальный сеансовый ключ, которым он пользуется совместно с инициатором запроса.