Безопасное сетевое взаимодействие (часть 1)

Более безопасный аутентификационный протокол

Хотя описанный сценарий и решает часть проблем аутентификации в открытых сетевых окружениях, многие проблемы все еще остаются. В частности, следует решить следующие две задачи. Во-первых, сделать так, чтобы пользователю приходилось вводить пароль минимальное количество раз. Пока предполагается, что каждый билет может использоваться только один раз. Если пользователь С хочет проверить свою почту на почтовом сервере, он должен предоставить пароль для получения билета на почтовый сервер. Если С хочет проверить почту несколько раз в течение дня, каждое обращение к почтовому серверу требует повторного ввода пароля. Эту процедуру можно усовершенствовать, разрешив переиспользовать билеты. При первой входной сессии рабочая станция может запомнить полученный билет сервера и использовать его от имени пользователя в дальнейшем при доступе к этому серверу.

Однако при такой схеме пользователю необходим новый билет для каждого нового сервера. Если пользователь хочет получить доступ к серверу печати, почтовому серверу, файловому серверу и т.д., то при первом доступе к каждому серверу будет требоваться ввод пароля.

Вторая проблема состоит в том, что ранее рассмотренный сценарий включает незашифрованную передачу пароля в первом сообщении. Оппонент может перехватить пароль и использовать любой доступный данному пользователю сервис.

Для решения этих проблем рассмотрим схему, которая не допускает незашифрованных паролей, и введем новый сервер, называемый сервером предоставления билетов (ticket-granting server - TGS ). Этот сценарий состоит в следующем:

Один раз при входе пользователя:

1. C -> AS: ID_C, ID_tgs
2. AS -> C: E_Kc [Ticket_tgs]

Один раз для каждого типа сервиса:

3. C -> TGS: ID_C, ID_S, Ticket_tgs
4. TGS -> C: Ticket_S

Один раз для каждого доступа к сервису:

5. C -> S: ID_C, Ticket_S

Tickettgs = EKtgs [IDC, ADC, IDtgs, TS1, LT1]
TicketS = EKs [IDC, ADC, IDS, TS2, LT2]

Пользователь первым делом получает билет, гарантирующий билет, Ticket_tgs от AS . Этот билет хранится в модуле клиента на рабочей станции пользователя. Сервер TGS выдает билеты пользователям, которые перед этим были аутентифицированы AS . Каждый раз, когда пользователю требуется новый сервис, клиентский модуль обращается к TGS , используя предоставленный AS билет, и TGS выдает билет для конкретного сервиса. Клиентский модуль хранит каждый гарантирующий сервис билет и использует его для аутентификации на сервере всякий раз, когда требуется конкретный сервис. Рассмотрим данную схему подробнее:

1. Клиентский модуль запрашивает билет, гарантирующий билет, посылая идентификатор пользователя к AS вместе с идентификатором TGS , который будет в дальнейшем использоваться для получения билета, гарантирующего сервис.

2. AS в ответ присылает билет, зашифрованный ключом, полученным из пароля пользователя. Когда этот ответ поступает в клиентский модуль, он просит пользователя ввести свой пароль, создает ключ и пытается расшифровать полученное сообщение. Если используется корректный пароль, то билет успешно извлекается.

   Так как только законный пользователь должен знать пароль, только законный пользователь и может получить билет. Таким образом, пароль используется для получения доверительной грамоты от Kerberos без передачи пароля в незашифрованном виде. Сам билет включает идентификатор и сетевой адрес пользователя и идентификатор TGS . Это соответствует первому сценарию. Необходимо, чтобы такой билет мог использоваться клиентским модулем для запроса нескольких билетов, гарантирующих предоставление сервиса. Следовательно, билет, гарантирующий билет, с одной стороны, должен быть переиспользуемым. Но с другой стороны, необходимо добиться того, чтобы оппонент не мог перехватывать этот билет и использовать его. Рассмотрим следующий сценарий: оппонент перехватывает билет и ждет до тех пор, пока пользователь не завершит регистрацию на своей рабочей станции. Тогда оппонент пытается получить доступ к этой рабочей станции или сконфигурировать свою рабочую станцию с тем же сетевым адресом, что и у законного пользователя. После этого оппонент будет иметь возможность переиспользовать билет для обмана TGS . Чтобы этого не произошло, билет включает отметку времени, определяющую дату и время, когда был получен билет, и время жизни, определяющую величину времени, в течение которого билет является действительным (например, 8 часов). Таким образом, теперь клиентский модуль имеет переиспользуемый билет, и нет необходимости требовать от пользователя ввода пароля для получения нового сервиса. В заключении заметим, что билет, гарантирующий билет, шифруется секретным ключом, известным только AS и TGS . Это предотвращает модификацию билета. Билет повторно зашифровывается ключом, основанным на пароле пользователя. Это гарантирует, что билет может быть восстановлен только законным пользователем, прошедшим аутентификацию.

   Теперь, когда клиентский модуль имеет билет, гарантирующий билет, доступ к любому серверу можно получить, выполнив шаги (3) и (4):
3. Клиентский модуль запрашивает билет, гарантирующий сервис. Для этой цели клиентский модуль передает TGS сообщение, содержащее идентификатор пользователя, идентификатор требуемого сервиса и билет, гарантирующий билет.

4. TGS расшифровывает входящий билет и проверяет успешность дешифрования по наличию своего идентификатора. Также необходимо убедиться, что время жизни данного билета не истекло. Затем TGS сравнивает идентификатор пользователя и его сетевой адрес со значениями, полученными из билета. После этого TGS выдает билет, гарантирующий доступ к нужному сервису.

   Билет, гарантирующий сервис, имеет ту же структуру, что и билет, гарантирующий билет. Этот билет также содержит отметку времени и время жизни. Если пользователь захочет получить доступ к тому же самому сервису позднее, клиентский модуль может просто использовать ранее полученный билет, гарантирующий сервис, и нет необходимости повторно запрашивать пароль пользователя. Заметим, что билет зашифрован с помощью секретного ключа E_Ks, известного только TGS и серверу, что предотвращает его изменение.

   Наконец, с билетом, гарантирующим сервис, клиентский модуль может получить доступ к соответствующему сервису:
5. Клиентский модуль запрашивает доступ к сервису от имени пользователя. С этой целью клиентский модуль передает сообщение серверу, содержащее идентификатор пользователя и билет, гарантирующий сервис. Сервер аутентифицирует пользователя, используя содержимое билета.

Этот новый сценарий позволяет сделать так, чтобы за время работы пользователя пароль запрашивался только один раз, и обеспечивает защиту пароля пользователя.