Московский государственный университет имени М.В.Ломоносова
Опубликован: 26.01.2005 | Доступ: свободный | Студентов: 4923 / 1272 | Оценка: 4.17 / 3.92 | Длительность: 21:54:00
ISBN: 978-5-9556-0020-8
Лекция 8:

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

Области Kerberos

Полнофункциональное окружение Kerberos, состоящее из сервера Kerberos, некоторого числа клиентов и некоторого числа прикладных серверов, требует следующего:

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

    Такое окружение называется областью ( realm ). Сети из клиентов и серверов в различных административных организациях обычно образовывают различные области. Однако пользователи из одной области могут нуждаться в доступе к серверам из других областей, и некоторые серверы готовы предоставлять сервисы пользователям из других областей, если эти пользователи будут аутентифицированы.

    Kerberos предоставляет механизм для поддержки такой аутентификации между областями. Для двух областей, поддерживающих межобластную аутентификацию, добавлено следующее требование:

  3. Сервер Kerberos для каждой из взаимодействующих областей разделяет секретный ключ с сервером Kerberos в другой области. Другими словами, два сервера Kerberos регистрируют друг друга.

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

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

Протокол обмена является следующим:

  1. C -> AS: IDC, IDtgs, TS1
  2. AS -> C: EKc [KC, tgs, IDtgs, TS2, LТ2, Tickettgs]
  3. C -> TGS: IDtgsrem, Tickettgs, AuthenticatorC
  4. TGS -> C: EKc, tgs [KC, tgsrem, IDtgsrem, TS4, Tickettgsrem]
  5. C -> TGSrem: IDrem, Tickettgsrem, AuthenticatorC
  6. TGSrem -> C: EKc, tgsrem [KC, Srem, IDSrem, TS6, TicketSrem]
  7. C -> Srem: TicketSrem, AuthenticatorC

Билет, предоставляемый удаленному серверу Srem, кроме всего остального, содержит идентификатор области, в которой пользователь был аутентифицирован. Сервер определяет, является ли данный удаленный запрос законным.

При таком подходе традиционная проблема состоит в том, что если существует N областей, то должно быть [N (N - 1)]/2 безопасных обменов ключей, чтобы каждый Kerberos области мог взаимодействовать со всеми остальными Kerberos.

Илья Сидоркин
Илья Сидоркин

Добрый день! Подскажите пожалуйста как и когда получить диплом, после сдичи и оплаты?????

Наталья Шульга
Наталья Шульга

Курс "информационная безопасность" .

Можно ли на него записаться на ПЕРЕПОДГОТОВКУ по данному курсу? Выдается ли диплом в бумажном варианте и высылается ли он по почте?