Каталог Рефератов - Протокол Kerberos - скачать рефераты, бесплатно рефераты

	Информационно-образоательный портал
	Рефераты, курсовые, дипломы, научные работы,



МЕНЮ\|

поиск

Протокол Kerberos

теперь рассмотрим, что происходит, когда пользователь с учетной записью в домене "Восток" запрашивает доступ к серверу из домена "Запад". Прежде всего, клиент Kerberos, установленный на рабочей станции этого пользователя, посылает запрос в службу выдачи билетов своего домена, в котором просит выдать сеансовый билет для доступа на нужный сервер. Служба выдачи билетов домена "Восток" проверяет список своих абонентов безопасности и убеждается, что такого сервера среди них нет. Поэтому она направляет клиенту так называемый билет переадресации (referral ticket), который представляет собой TGT, зашифрованный с помощью междоменного ключа, общего для служб KDC доменов "Восток" и "Запад". Получив билет переадресации, клиент использует его для подготовки другого запроса на сеансовый ключ. Однако на этот раз запрос пересылается в службу выдачи билетов того домена, где находится учетная запись нужного сервера, то есть, домена "Запад". Его служба выдачи билетов пытается расшифровать билет переадресации с помощью собственной копии междоменного ключа. Если попытка удается, центр KDC направляет клиенту сеансовый билет на доступ к соответствующему серверу своего домена.

Процесс переадресации запроса несколько усложняется в сетях, где развернуто более двух доменов. Теоретически служба KDC каждого домена может установить непосредственную связь с аналогичными службами всех доменов сети, договорившись с каждой из них об индивидуальном междоменном ключе. Однако на практике количество и сложность подобных взаимосвязей очень быстро возрастают до такой степени, что становятся просто неуправляемыми, особенно в сложных сетях. Протокол Kerberos решает эту проблему, делая ненужными прямые связи между доменами. Клиент одного домена может получить билет на доступ к серверу другого домена через один или несколько промежуточных серверов, каждый из которых выдаст ему билет переадресации.

В качестве примера рассмотрим сеть, состоящую из трех доменов: "Восток", "Запад" и "Штаб-квартира". В службе KDC домена "Восток" нет междоменного ключа для аналогичной службы домена "Запад", но центры распределения ключей обоих доменов наладили обмен билетами с доменом "Штаб-квартира". Когда пользователь с учетной записью в домене "Восток" хочет подключиться к серверу из домена "Запад", его запрос будет переадресован дважды. Сначала он пройдет через службу KDC "родного" домена, затем - через промежуточный домен "Штаб-квартира" и, наконец, достигнет центра распределения ключей домена "Запад", которому известен ключ нужного сервера. Таким образом, клиент здесь посылает сеансовые билеты трижды в три различные службы KDC.

1. Клиент запрашивает у службы KDC домена "Восток" билет на доступ к серверу домена "Запад". Служба KDC домена "Восток" направляет клиенту билет переадресации в службу KDC домена "Штаб-квартира", зашифрованный с междоменным ключом, общим для доменов "Восток" и "Штаб-квартира".

2. Клиент обращается в службу KDC домена "Штаб-квартира" с просьбой о билете на доступ к серверу домена "Запад". Служба KDC домена "Штаб-квартира" направляет клиенту билет переадресации в службу KDC домена "Запад", зашифрованный с междоменным ключом, общим для доменов "Штаб-квартира" и "Запад".

3. Клиент обращается в службу KDC домена "Запад" с просьбой о билете на доступ к серверу домена "Запад". Служба KDC домена "Запад" направляет клиенту билет на доступ к нужному серверу.

Подпротоколы
Протокол Kerberos содержит в себе три подпротокола. Первый из них используется службой KDC для передачи клиенту сеансового ключа регистрации и билета TGT. Он называется Authentication Service Exchange (обмен со службой аутентификации) или, сокращенно AS Exchange. Второй подпротокол под названием Ticket-Granting Service Exchange (обмен со службой выдачи билетов) или TGS Exchange служит для рассылки служебных сеансовых ключей и сеансовых ключей самой службы KDC. Третий подпротокол, Client/Server Exchange (клиент-серверный обмен) или CS Exchange, используется клиентом для пересылки сеансового билета доступа к службам.

Чтобы лучше разобраться в том, как эти подпротоколы взаимодействуют между собой, давайте посмотрим, что происходит, когда Алиса, пользователь рабочей станции, обращается к Бобу, сетевой службе.

Рисунок.5. Подпротокол AS Exchange

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

После того, как проверка личности Алисы завершена, служба KDC генерирует удостоверение, подтверждающее, что клиент Kerberos на ее рабочей станции имеет право обратиться к службе выдачи билетов. Этот процесс выполняется в два этапа. Во-первых, KDC создает сеансовый ключ регистрации и шифрует его копию с помощью долговременного ключа Алисы. Во-вторых, служба включает еще одну копию сеансового ключа регистрации в билет TGT. Туда же заносятся и другая информация об Алисе, например, ее данные авторизации. Затем KDC шифрует билет TGT с собственным долговременным ключом и, наконец, включает зашифрованный сеансовый ключ регистрации вместе с билетом TGT в пакет KRB_AS_REP (Kerberos Authentication Service Reply - ответ службы аутентификации Kerberos), который направляет клиенту.

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

Подпротокол TGS Exchange
Клиент Kerberos, установленный на рабочей станции Алисы, запрашивает удостоверение на доступ к службе Боб, для чего посылает в службу KDC сообщение KRB_TGS_REQ (Kerberos Ticket-Granting Service Request - запрос к службе выдачи билетов Kerberos). В него включается имя пользователя, аутентификатор, зашифрованный с помощью сеансового ключа регистрации Алисы, билет TGT, который был получен с помощью подпротокола AS Exchange, а также имя службы, на доступ к которой нужен билет.

Рисунок.6. Подпротокол TGS Exchange

Получив запрос KRB_TGS_REQ, служба KDC с помощью собственного секретного ключа расшифровывает билет TGT и извлекает из него сеансовый ключ регистрации Алисы, который тут же использует для расшифровки аутентификатора. Если содержимое аутентификатора выдерживает проверку, служба KDC извлекает из билета TGT регистрационные данные Алисы и генерирует сеансовый ключ, общий для клиента Алисы и службы Боб. Одну копию этого ключа KDC шифрует с помощью сеансового ключа регистрации Алисы, а другую вместе с данными авторизации Алисы помещает в билет, который шифрует с помощью долговременного ключа Боба. После этого удостоверение Алисы включается в пакет KRB_TGS_REP (Kerberos Ticket-Granting Service Reply - ответ службы выдачи билетов Kerberos) и направляется на ее рабочую станцию.

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

Подпротокол CS Exchange
Клиент Kerberos, установленный на рабочей станции Алисы, обращается к службе Боб, для чего посылает на нее запрос KRB_AP_REQ (Kerberos Application Request - запрос приложения Kerberos). Это сообщение содержит аутентификатор Алисы, зашифрованный посредством сеансового ключа для службы Боб, билет, полученный с помощью протокола TGS Exchange, а также флаг, указывающий о желании клиента провести взаимную аутентификацию (наличие или отсутствие этого флага определяется конфигурацией Kerberos; он устанавливается автоматически без запроса пользователя).

Рисунок.7. Подпротокол CS Exchange

Получив сообщение KRB_AP_REQ, служба Боб расшифровывает билет, извлекает из него данные авторизации Алисы и сеансовый ключ, с помощью которого сразу же расшифровывает аутентификатор Алисы. Если метка времени, заложенная в него, выдерживает проверку, Боб ищет в запросе флаг взаимной аутентификации. Найдя его, Боб шифрует метку времени из аутентификатора Алисы сеансовым ключом, включает полученный результат в пакет KRB_AP_REP (Kerberos Application Reply - ответ приложения Kerberos) и возвращает его на рабочую станцию Алисы.

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

Билеты
Выше мы говорили о билетах лишь в общих чертах. Теперь пришло время более подробно рассмотреть, что же это такое, как рассчитывается срок годности билета, и какая его часть становится известной клиенту. Все эти детали важны для разработки политики Kerberos, поэтому к ним нужно присмотреться как можно ближе.

Что такое билет
В рамках данного информационного документа достаточно перечислить поля билета и описать содержащуюся в них информацию. Более подробно структура билета и различных сообщений Kerberos описана в документе RFC 1510, как представлено в таблице 1.

Таблица 1 - Структура билета и различных сообщений Kerberos

Название поля	Описание
	Первые три поля билета не шифруются. Содержащаяся здесь информация пересылается открытым текстом, что позволяет клиенту использовать ее для управления билетами, хранящимися в кэш-памяти.
tkt-vno	Номер версии формата билета. Для Kerberos 5 здесь указывается цифра 5.
Realm	Имя области (домена), где генерирован билет. Служба KDC может создавать билеты только для серверов собственной области, поэтому здесь, по существу, указывается имя области, где расположен сервер.
Sname	Имя сервера
Flags	Флаги билета.
Key	Сеансовый ключ
Crealm	Имя области (домена) клиента.
Cname	Имя клиента.
Transited	Список областей Kerberos, принимавших участие в аутентификации клиента, которому выдан данный билет.
Authtime	Время первоначальной аутентификации клиента. Служба KDC заполняет это поле в момент генерации билета TGT. При генерации билетов на основе билета TGT временная метка из поля authtime билета TGT копируется в поле authtime генерируемого билета.
Starttime	Время вступления билета в силу.
Endtime	Время истечения срока действия билета.
renew-till	Наибольшее значение поля endtime, которое может быть задано с помощью флага RENEWABLE (поле необязательное).
Caddr	Один или несколько адресов, из которых может использоваться данный билет. Поле необязательное. Если оно не заполнено, билетом можно воспользоваться из любого адреса.
Authorization-data	Атрибуты привилегий клиента. Поле необязательное. Его содержимое Kerberos не обрабатывает - оно интерпретируется службой.

Содержимое поля flags адресуется побитно. Включение и выключение флагов здесь производится изменением значения (0 или 1) соответствующего бита. Длина поля - 32 разряда, однако для администратора Kerberos интерес представляют только 9 флагов билета, представленные в таблице 2.

Таблица 2 - Флаги билета Kerberos

Флаг	Описание
FORWARDABLE	Указывает, что на основании данного билета TGT служба выдачи билетов может генерировать новый билет TGT с другим сетевым адресом (поле имеется только в билетах TGT).
FORWARDED	Указывает на то, что данный билет TGT был переадресован или генерирован на основе другого билета TGT, прошедшего переадресацию.
PROXY	Указывает на то, что сетевой адрес в данном билете отличается от адреса, приведенного в билете TGT, на основании которого он выдан.
RENEWABLE	Используется в сочетании с полями endtime и renew-till, разрешая периодическое обновление службой KDC билетов с повышенным срока действия.
INITIAL	Указывает, что данный билет является билетом выдачи билетов (поле имеется только в билетах TGT).

Какие данные из билета известны клиенту
Клиенту необходимо знать часть информации, содержащейся как в обычных билетах, так и в билетах TGT, чтобы управлять своей кэш-памятью удостоверений. Возвращая билет и сеансовый ключ в рамках подпротоколов AS Exchange или TGS Exchange, служба KDC упаковывает клиентскую копию сеансового ключа в структуру данных, где уже могут быть заполнены поля flags, authtime, starttime, endtime и renew-till. Вся эта структура шифруется с помощью ключа клиента, включается в пакет KRB_AS_REP или KRB_TGS_REP и возвращается на рабочую станцию клиента.

Как служба KDC ограничивает срок действия билета
В билете указывается время начала и конца его действия. В течение этого промежутка клиент, которому выдан данный билет, может неограниченное количество раз представить его для получения доступа к службе. Чтобы уменьшить риск компрометации билета или соответствующего сеансового ключа, администратор вправе ограничить максимальный срок действия билета. Этот срок является одним из элементов политики Kerberos.

Запрашивая в центре KDC билет для доступа к службе, клиент может указать конкретное время начала его действия. Если этого не сделано или заданное время уже минуло, центр KDC указывает в поле starttime текущее время.

Но независимо от того, указал клиент время начала действия билета или нет, запрос обязательно должен содержать время прекращения срока его действия. Получив такой запрос, служба KDC рассчитывает значение поля endtime. Для этого она суммирует наибольший срок действия билета, предусмотренный политикой Kerberos, со значением поля starttime, а затем сравнивает полученный результат со временем прекращения действия билета, указанным в запросе клиента. Если они не совпадают, в поле endtime заносится то время, которое наступит раньше.

Что происходит после истечения срока действия билета
О скором истечении срока действия сеансового билета или билета TGT служба KDC не уведомляет клиента. Не следит она и за транзакциями с клиентом, если не считать краткосрочных записей, главная цель которых - предотвратить повторное использование перехваченных пакетов.

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

Может случиться и так, что клиент включит просроченный билет TGT в свой запрос на сеансовый билет, который направит в службу KDC. В этом случае центр выдачи билетов перешлет клиенту сообщение об ошибке, после чего клиенту придется запросить новый билет TGT, а для этого ему понадобится долговременный ключ пользователя. Если в процессе начальной регистрации такой ключ не был занесен в кэш-память, система может попросить пользователя еще раз ввести свой пароль, на основании которого будет вновь рассчитан долговременный ключ.

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

Поле endtime указывает, когда истекает срок действия текущего экземпляра билета. Как и в случае с необновляемыми билетами, значение этого поля равно сумме значения из поля starttime и наибольшего срока действия билетов, определенного политикой Kerberos. Клиент, использующий обновляемый билет, должен представить его в службу KDC для обновления до времени, указанного в поле endtime. Одновременно с билетом в центр распределения ключей направляется и новый аутентификатор. Получив билет, который нужно обновить, служба KDC, прежде всего, проверяет общий срок его действия, указанный в поле renew-till. Это время задается при первичной генерации билета. Оно определяется путем суммирования значения из поля starttime с максимально допустимым политикой Kerberos сроком действия билета с учетом всех обновлений. Если указанное в поле renew-till время еще не наступило, служба KDC генерирует новый экземпляр билета, где указывает более позднее время endtime и заменяет сеансовый ключ.

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

Делегирование аутентификации
Определенную сложность для протокола Kerberos создают многоуровневые клиент-серверные приложения. Здесь клиент может подключаться к серверу, который, в свою очередь, должен будет подключиться к другому серверу более высокого уровня. Для этого первому серверу понадобится билет на подключение ко второму. В идеале такой билет должен ограничивать доступ первого сервера ко второму лишь теми функциями, на которые клиент имеет права.

Для решения этой проблемы в протоколе Kerberos имеется специальный механизм - так называемое делегирование аутентификации. По существу, в такой ситуации клиент поручает свою аутентификацию серверу. С этой целью он уведомляет службу KDC о том, что данный сервер имеет право представлять клиента. Такой подход напоминает концепцию имперсонации (concept of impersonation) Windows 2000.

Делегирование аутентификации возможно двумя способами. Во-первых, клиент может получить билет на подключение к серверу высшего уровня, а затем передать его ближайшему серверу. Билеты, полученные таким способом - клиентом для ближайшего сервера - называются представительскими (proxy tickets). Однако на этом пути имеется одна серьезная трудность: чтобы получить представительский билет, клиенту нужно знать имя сервера высшего уровня. Решить проблему помогает второй способ делегирования аутентификации. Здесь клиент передает на ближайший к нему сервер свой билет TGT, который тот по мере необходимости использует для запроса собственных билетов. Билеты TGT, полученные таким образом, то есть, по удостоверению клиента, называются передаваемыми (forwarded tickets). Какой из описанных способов применяется службой KDC, зависит от политики Kerberos.

Вывод
Kerberos это - сетевой протокол аутентификации, позволяющий безопасно передавать данные через незащищённые сети для безопасной идентификации. Также является набором бесплатного ПО от Массачусетского технологического института (Massachusetts Institute of Technology (MIT)), разработавшего этот протокол. Её организация направлена в первую очередь на клиент-серверную модель и обеспечивает взаимную аутентификацию - оба пользователя через сервер подтверждают личности друг друга. Сообщения, отправляемые через протокол Kerberos, защищены от прослушивания и атак повторного воспроизведения.

Kerberos является одним из вариантов протокола Нидхема-Шрёдера, основан на симметричной криптосистеме и требует третье доверенное лицо (сервер). Расширение Kerberos позволяет использовать открытые ключи в процессе аутентификации.

Список использованных исочников

1. По материалам ресурса http://ru.wikipedia.org/wiki/Kerberos

2. По материалам ресурса http://www.oszone.net/4188_4/Kerberos

Страницы: 1, 2, 3

© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.