МОСКОВСКАЯ ФИНАНСОВАЯ ПРОМЫШЛЕННАЯ АКАДЕМИЯ
КУРСОВАЯ РАБОТА
по предмету
«Безопасность и управление доступом»
на тему:
«Протокол Kerberos»
Выполнил: студент 4 курса
Румянцев Сергей
Проверил: преподаватель
Кудряев А.В,
г. Бронницы 2010 г.
Оглавление
Введение
Аутентификация в Windows 2000
Преимущества аутентификации по протоколу Kerberos
Стандарты аутентификации по протоколу Kerberos
Расширения протокола Kerberos
Обзор протокола Kerberos
Основные концепции
Аутентификаторы
Управление ключами
Сеансовые билеты
Билеты на выдачу билетов
Аутентификация за пределами домена
Подпротоколы
Подпротокол TGS Exchange
Подпротокол CS Exchange
Билеты
Что такое билет
Какие данные из билета известны клиенту
Как служба KDC ограничивает срок действия билета
Что происходит после истечения срока действия билета
Обновляемые билеты TGT
Делегирование аутентификации
Вывод
Список использованных исочников
Введение
Настоящий документ представляет технические аспекты реализациипротокола аутентификации Kerberos 5 в операционной системе Microsoft® Windows® 2000.Здесь приводится подробное описание важнейших концепций, архитектурных элементов,а также функций аутентификации по протоколу Kerberos. Первый раздел «Обзорпротокола Kerberos» предназначен тем, кто не знаком с этим протоколом. Последующиеразделы посвящены более подробному описанию того, как Microsoft реализовала Kerberosв операционной системе Windows 2000. Завершается информационный документ краткимобсуждением вопросов взаимодействия описываемого протокола с другими реализациямиKerberos.
Аутентификация в Windows 2000
Windows 2000 поддерживает несколько протоколов, которые позволяютубедиться в том, что входящий в систему пользователь действительно имеет здесь своюучетную запись. Среди них — протоколы аутентификации удаленных подключений и протоколыаутентификации пользователей, входящих в сеть через Интернет. Однако внутри доменовWindows 2000 для проверки пользовательских данных предусмотрено два метода:
1) Kerberos версия 5. Протокол Kerberos 5 является стандартным средством аутентификациисетевых пользователей в домене Active Directory на всех компьютерах с операционнойсистемой Windows 2000;
2) Windows NT LAN Manager (NTLM). Протокол NTLM применялсяв качестве стандартного средства сетевой аутентификации в операционной системе WindowsNT® 4.0. В среде Windows 2000 он используется для аутентификации серверов и доменовWindows NT 4.0. Кроме того, NTLM применяется для локальной аутентификации на автономныхкомпьютерах, работающих под управлением Windows 2000.
Компьютеры под управлением Windows 3.11, Windows 95, Windows98 и Windows NT 4.0 смогут использовать протокол NTLM для сетевой аутентификациив доменах Windows 2000. Компьютерам же, работающим под управлением Windows 2000,этот протокол обеспечит аутентификацию на серверах Windows NT 4.0 и откроет доступк ресурсам доменов Windows NT 4.0. Однако в тех случаях, когда есть выбор, в средеWindows 2000 по умолчанию будет использоваться протокол Kerberos 5.
Преимущества аутентификации по протоколу Kerberos
Протокол Kerberos выгодно отличается от NTLM большей гибкостьюи эффективностью использования. Обеспечивает он и повышенный уровень безопасности.Ряд преимуществ, которые дает переход на Kerberos, приводится ниже.
1. Более эффективная аутентификация на серверах. При аутентификациипо протоколу NTLM серверу приложений приходится подключаться к контроллеру доменапри проверке каждого клиента. С Kerberos такая необходимость отпадает — здесь аутентификацияпроизводится за счет проверки удостоверения, представленного клиентом. Индивидуальноеудостоверение клиент получает от контроллера единожды, после чего может неоднократноиспользовать его на протяжении всего сеанса работы в сети.
2. Взаимная аутентификация. Протокол NTLM позволяет серверу идентифицироватьсвоих клиентов, однако не предусматривает верификации сервера ни клиентами, ни другимисерверами. Этот протокол разрабатывался для сетей, в которых все серверы считаютсялегитимными. В отличие от него, Kerberos такого допущения не делает, поэтому проверяетобоих участников сетевого подключения, каждый из которых в результате может точноузнать, с кем поддерживает связь.
3. Делегированная аутентификация. Когда клиент сети Windows обращаетсяк ресурсам, службы операционной системы, прежде всего, производят его идентификацию.Во многих случаях для выполнения этой операции службе достаточно информации на локальномкомпьютере. Как NTLM, так и Kerberos обеспечивают все данные, необходимые для идентификациипользователя на месте, однако иногда их бывает недостаточно. Некоторые распределенныеприложения требуют, чтобы при подключении к серверным службам на других компьютерахидентификация клиента производилась локально службой самого этого клиента. Решитьпроблему помогает Kerberos, где предусмотрен специальный механизм представительскихбилетов, который позволяет на месте идентифицировать клиента при его подключениик другим системам. В протоколе NTLM такая возможность отсутствует.
4. Упрощенное управление доверительными отношениями. Одно изважных достоинств взаимной аутентификации по протоколу Kerberos состоит в том, чтодоверительные отношения между доменами Windows 2000 по умолчанию являются двустороннимии транзитивными. Благодаря этому в сетях с множеством доменов не придется устанавливатьмного явных доверительных отношений. Вместо этого все домены большой сети можносвести в дерево транзитивных отношений взаимного доверия. Удостоверение, выданноесистемой безопасности для любого домена, может приниматься во всех ветвях дерева.Если же сеть содержит несколько деревьев, то удостоверение любого из них будет приниматьсяпо всему «лесу».
5. Совместимость. В основу своей реализации протокола Kerberosкорпорация Microsoft положила стандартные спецификации, рекомендованные группойIETF. Благодаря такому подходу удалось обеспечить аутентификацию клиентов Windows2000 во всех сетях, которые поддерживают Kerberos 5.
Стандарты аутентификации по протоколу Kerberos
Протокол Kerberos был создан в Массачусетском технологическоминституте в рамках проекта Athena. Однако общедоступным этот протокол стал лишьпосле появления версии 4. После того, как специалисты отрасли изучили новый протокол,его авторы разработали и предложили пользователям очередную версию — Kerberos 5,которая и была принята в качестве стандарта IETF. Реализация протокола в Windows2000 выполнена в строгом соответствии с требованиями, изложенными в документе RFC1510. Кроме того, при ее разработке были использованы механизм и формат передачиконтекстов безопасности в сообщениях Kerberos, описанные в спецификациях Интернетаиз документа RFC 1964.
Расширения протокола Kerberos
В Windows 2000 нашли применение расширения протокола Kerberos,упрощающие начальную аутентификацию клиентов. Обычно для этой цели используютсясекретные ключи, которыми должны заранее обменяться между собой участники сеанса,но теперь такую процедуру можно провести с помощью открытых ключей. Благодаря этомупоявилась возможность интерактивной регистрации пользователя с помощью микропроцессорныхкарточек. В основу расширений, обеспечивающих аутентификацию с открытым ключом,положена спецификация PKINIT.
Обзор протокола Kerberos
Протокол аутентификации Kerberos предлагает механизм взаимнойидентификации клиента и сервера (или двух серверов) перед установлением связи междуними. В протоколе учтено, что начальный обмен информацией между клиентами и серверамипроисходит в открытой среде, а пакеты, передаваемые по каналам связи, могут бытьперехвачены и модифицированы. Другими словами, протокол предназначен для работыв среде, которая очень напоминает сегодняшний Интернет. Здесь злоумышленник легкоможет имитировать запросы клиента или сервера, перехватывать связь между легитимнымиклиентами и серверами, даже искажать передаваемую информацию.
Основные концепции
Протокол Kerberos активно использует технологии аутентификации,опирающиеся на «секреты для двоих». Основная концепция довольно проста:если есть секрет, известный только двоим, любой из его хранителей может легко удостовериться,что имеет дело именно со своим напарником. Для этого ему достаточно каким-либо способомпроверить, знает ли собеседник их общий секрет.
Рассмотрим это на простом примере. Допустим, Алиса часто посылаетсообщения Бобу, который использует содержащуюся в них информацию только тогда, когдаполностью уверен, что она поступила именно от Алисы. Чтобы никто другой не смогподделать письма, они договорились о пароле, который пообещали никому больше неговорить. Если из сообщения можно будет заключить, что отправитель знает этот пароль,Боб может точно сказать: оно пришло от Алисы.
Теперь Бобу и Алисе остается только решить, каким образом показатьсвое знание пароля. Можно, скажем, просто включить его в текст сообщения, например,после подписи: «Alice, Our$ecret». Это было бы очень просто, удобно инадежно, если бы Алиса и Боб были уверены, что никто другой не читает их сообщений.Однако почта передается по сети, где работают и другие пользователи, а среди нихесть Кэрол, которая очень любит подключать к сети свой анализатор пакетов в надеждевыведать чьи-нибудь секреты. И становится совершенно ясно, что Алиса не может простоназвать пароль в тексте письма. Чтобы секрет оставался секретом, о нем нельзя говоритьоткрыто, нужно найти способ только дать знать собеседнику, что он тебе известен.
В протоколе Kerberos эта проблема решается средствами криптографиис секретным ключом. Вместо того чтобы сообщать друг другу пароль, участники сеансаобмениваются криптографическим ключом, знание которого подтверждает личность собеседника.Один из участников использует такой ключ для шифрования блока информации, а другойс его помощью извлекает эту информацию.
Аутентификаторы
Простой протокол аутентификации с секретным ключом вступает вдействие, когда кто-либо стучится в сетевую дверь и просит впустить его. Чтобы доказатьсвое право на вход, пользователь предъявляет аутентификатор (authenticator) в видеблока информации, зашифрованного с помощью секретного ключа. Содержание этого блокадолжно меняться при каждом последующем сеансе, в противном случае злоумышленниквполне может проникнуть в систему, воспользовавшись перехваченным сообщением. Получиваутентификатор, привратник расшифровывает его и проверяет полученную информацию,чтобы убедиться в успешности расшифрования. Если все прошло нормально, страж можетбыть уверен, что человеку, предъявившему аутентификатор, известен секретный ключ.А ведь этот ключ знают всего двое, причем один из них — сам привратник. Таким образом,он делает вывод, что пришелец действительно тот человек, за которого себя выдает.
Но может случиться и так, что субъект, постучавшийся в дверь,захочет провести взаимную аутентификацию. В этом случае используется тот же самыйпротокол, но в обратном порядке и с некоторыми изменениями. Теперь привратник извлекаетиз исходного аутентификатора часть информации, а затем шифрует ее, превращая в новыйаутентификатор, и в таком виде возвращает пришельцу. Тот, в свою очередь, расшифровываетполученную информацию и сравнивает ее с исходной. Если все совпадает, пришелец можетбыть уверен: раз привратник расшифровал оригинал, значит, он знает секретный ключ.
А теперь вернемся к нашему примеру. Предположим, Алиса и Бобдоговорились: перед тем, как пересылать информацию между своими компьютерами, онис помощью известного только им двоим секретного ключа, будут проверять, кто находитсяна другом конце линии. В ситуации, когда Алиса играет роль осторожного гостя, аБоб — бдительного привратника, это будет выглядеть так.
1. Алиса посылает Бобу сообщение, содержащее ее имя в открытомвиде и аутентификатор, зашифрованный с помощью секретного ключа, известного толькоим двоим. В протоколе аутентификации такое сообщение представляет собой структуруданных с двумя полями. Первое поле содержит информацию об Алисе — ее имя. Во второмполе указывается текущее время на рабочей станции Алисы.
2. Боб получает сообщение и видит, что оно пришло от кого-то,кто называет себя Алисой. Он сразу же достает ключ, которым они с Алисой договорилисьшифровать аутентификатор, и, расшифровав второе поле, узнает время отправки сообщения.
Задача Боба намного упрощается, если его компьютер работает синхроннос компьютером Алисы, поэтому давайте предположим, что оба они сверяют свои часыс сетевым временем, благодаря чему те идут практически одинаково. Допустим, часына компьютерах Алисы и Боба никогда не расходятся больше, чем на пять минут. В этомслучае Боб может сравнить извлеченное из второго поля аутентификатора значение стекущим временем на своих часах. Если различие составит более пяти минут, компьютеравтоматически откажется признавать подлинность аутентификатора.
Если же время оказывается в пределах допустимого отклонения,можно с большой долей уверенности предположить, что аутентификатор поступил именноот Алисы. Но Бобу этого мало, ему нужна полная уверенность. Ведь, рассуждает он,может быть и так: кто-то перехватил предыдущую попытку Алисы связаться со мной итеперь пытается воспользоваться ее аутентификатором. Впрочем, если на компьютересохранились записи о времени аутентификаторов, поступивших от Алисы за последниепять минут, Боб может найти последний и отказаться от всех других сообщений, отправленныходновременно с ним или ранее. Но если второе поле свидетельствует, что сообщениеушло в сеть уже после отправки последнего аутентификатора Алисы, то и его авторомвполне могла быть Алиса.
3. Боб шифрует время из сообщения Алисы с помощью их общего ключаи включает его в собственное сообщение, которое направляет Алисе.
Обратите внимание, что Боб возвращает Алисе не всю информациюиз ее аутентификатора, а только время. Если бы он отправил все сразу, у Алисы закралосьбы подозрение, что кто-то, решив притвориться Бобом, просто скопировал аутентификаториз ее исходного сообщения и без каких-либо изменений отправил его назад. Но в полученномписьме содержится только часть информации, а это значит, что получатель исходногоаутентификатора смог расшифровать его и обработать содержащуюся там информацию.А время он выбрал потому, что это поле является уникальным идентификатором сообщенияАлисы. Алиса получает ответ Боба, расшифровывает его, а затем сравнивает полученныйрезультат со временем, которое было указано в исходном аутентификаторе. Если этиданные совпадают, она может быть уверена, что ее аутентификатор дошел до того, ктознает их с Бобом секретный ключ. Этот человек смог расшифровать сообщение и извлечьиз него информацию о времени. Поскольку ни она, ни Боб никому свой ключ не передавали,Алиса делает вывод, что именно Боб получил ее аутентификатор и ответил на него.Взаимная аутентификация представлена на рисунке 1.
/>
Рисунок 1 — Взаимная аутентификация (Алиса-Боб)
Управление ключами
При использовании простых протоколов, наподобие описанного выше,возникает одна очень важная проблема. В случае с Алисой и Бобом мы ни слова не сказалио том, как и где они договаривались о секретном ключе для своей переписки. Конечно,люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорахучаствуют машины. Если под Алисой понимать клиентскую программу, установленную нарабочей станции, а под Бобом — службу на сетевом сервере, то встретиться они никакне могут. Проблема еще более осложняется в тех случаях, когда Алисе — клиенту — нужно посылать сообщения на несколько серверов, ведь для каждого из них придетсяобзавестись отдельным ключом. Да и службе по имени Боб потребуется столько секретныхключей, сколько у нее клиентов. Но если каждому клиенту для поддержания связи скаждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службедля каждого клиента, то проблема обмена ключами очень быстро приобретает предельнуюостроту. Необходимость хранения и защиты такого множества ключей на огромном количествекомпьютеров создает невероятный риск для всей системы безопасности.
Само название протокола Kerberos говорит о том, как здесь решенапроблема управления ключами. Кербер (или Цербер) — персонаж классической греческоймифологии. Этот свирепый пес о трех головах, по поверьям греков, охраняет вратаподземного царства мертвых. Трем головам Кербера в протоколе Kerberos соответствуюттри участника безопасной связи: клиент, сервер и доверенный посредник между ними.Роль посредника здесь играет так называемый центр распределения ключей Key DistributionCenter или, сокращенно, KDC
KDC представляет собой службу, работающую на физически защищенномсервере. Она ведет базу данных с информацией об учетных записях всех главных абонентовбезопасности (security principal) своей области (области Kerberos в сетях Windows2000 соответствует домен, поэтому в дальнейшем мы будем применять именно этот привычныйтермин). Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняетсякриптографический ключ, известный только этому абоненту и службе KDC. Данный ключ,который называют долговременным, используется для связи пользователя системы безопасностис центром распределения ключей. В большинстве практических реализаций протоколаKerberos долговременные ключи создаются на основе пароля пользователя.
Когда клиенту нужно обратиться к серверу, он, прежде всего, направляетзапрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеансакопии уникального сеансового ключа (session key), действующие в течение короткоговремени. Назначение этих ключей — проведение аутентификации клиента и сервера. Копиясеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключаэтого сервера, а направляемая клиенту — долговременного ключа данного клиента.
/>
Рисунок.2. Управление ключами (в теории)
Теоретически, для выполнения функций доверенного посредника центруKDC достаточно направить сеансовые ключи непосредственно абонентам безопасности,как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно.Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памятидо тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента,поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания.В таких условиях управление ключами требует значительной затраты серверных ресурсов,что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевоготрафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовыйпароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результатесерверу придется повременить с ответом до тех пор, пока он не получит свою копиюсеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладываетна его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схемауправления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже.
Сеансовые билеты
В ответ на запрос клиента, который намерен подключиться к серверу,служба KDC направляет обе копии сеансового ключа клиенту, как показано на рис.3.Сообщение, предназначенное клиенту, шифруется посредством долговременного ключаклиента, а сеансовый ключ для сервера вместе с информацией о клиенте вкладываетсяв блок данных, получивший название сеансового билета (session ticket). Затем сеансовыйбилет целиком шифруется с помощью долговременного ключа сервера, который знают толькослужба KDC и данный сервер. После этого вся ответственность за обработку билета,несущего в себе зашифрованный сеансовый ключ, возлагается на клиента, который должендоставить его на сервер.
/>
Рисунок.3. Управление ключами (на практике)
Обратите внимание, что в данном случае функции службы KDC ограничиваютсявыдачей билета. Ей больше не нужно следить за тем, все ли отправленные сообщениядоставлены соответствующим адресатам. Даже если какое-нибудь из них попадет не туда,- ничего страшного не случится. Расшифровать клиентскую копию сеансового ключа можеттолько тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочестьсодержимое сеансового билета, нужен долговременный секретный ключ сервера. Получивответ KDC, клиент извлекает из него сеансовый билет и свою копию сеансового ключа,которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативнойпамяти). Когда возникает необходимость связаться с сервером, клиент посылает емусообщение, состоящее из билета, который по-прежнему зашифрован с применением долговременногоключа этого сервера, и собственного аутентификатора, зашифрованного посредствомсеансового ключа. Этот билет в комбинации с аутентификатором как раз и составляетудостоверение, по которому сервер определяет «личность» клиента.
/>
Рисунок.4. Взаимная аутентификация (клиент-сервер)
Сервер, получив «удостоверение личности» клиента, спомощью своего секретного ключа расшифровывает сеансовый билет и извлекает из негосеансовый ключ, который затем использует для расшифрования аутентификатора клиента.Если все проходит нормально, делается заключение, что удостоверение клиента выданодоверенным посредником, то есть, службой KDC. Клиент может потребовать у серверапроведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансовогоключа шифрует метку времени из аутентификатора клиента и в таком виде пересылаетее клиенту в качестве собственного аутентификатора.
Одно из достоинств применения сеансовых билетов состоит в том,что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняютсяв кэш-памяти удостоверений (credentials cache) клиента, который направляет билетна сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получивот клиента билет, расшифровывает его и извлекает сеансовый ключ. Когда надобностьв этом ключе исчезает, сервер может просто стереть его из своей памяти.
Такой метод дает и еще одно преимущество: у клиента исчезаетнеобходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером.Сеансовые билеты можно использовать многократно. На случай же их хищения устанавливаетсясрок годности билета, который KDC указывает в самой структуре данных. Это времяопределяется политикой Kerberos для конкретного домена. Обычно срок годности билетовне превышает восьми часов, то есть, стандартной продолжительности одного сеансаработы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется,и все сеансовые билеты вместе с сеансовыми ключами уничтожаются.
Билеты на выдачу билетов
Как уже отмечалось, долговременный ключ пользователя создаетсяна основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Алисапроходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускаетуказанный пользователем пароль через функцию хеширования (все реализации протоколаKerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применятьсяи другие алгоритмы). В результате формируется криптографический ключ.
В центре KDC долговременные ключи Алисы хранятся в базе данныхс учетными записями пользователей. Получив запрос от клиента Kerberos, установленногона рабочей станции Алисы, KDC обращается в свою базу данных, находит в ней учетнуюзапись нужного пользователя и извлекает из соответствующего ее поля долговременныйключ Алисы.
Такой процесс — вычисление одной копии ключа по паролю и извлечениедругой его копии из базы данных — выполняется всего лишь один раз за сеанс, когдапользователь входит в сеть впервые. Сразу же после получения пользовательского пароляи вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовыйбилет и сеансовый ключ, которые используются во всех последующих транзакциях с KDCна протяжении текущего сеанса работы в сети.
На запрос пользователя KDCотвечает специальным сеансовым билетомдля самого себя, так называемый билет на выдачу билетов (ticket-granting ticket),или билет TGT. Как и обычный сеансовый билет, TGT содержит копию сеансового ключадля связи службы (в данном случае — KDC) с клиентом. В сообщение с билетом TGT такжевключается копия сеансового ключа, с помощью которой клиент может связаться с KDC.Билет TGT шифруется посредством долговременного ключа службы KDC, а клиентская копиясеансового ключа — с помощью долговременного ключа пользователя.
Получив ответ службы KDC на свой первоначальный запрос, клиентрасшифровывает свою копию сеансового ключа, используя для этого копию долговременногоключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученныйиз пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится:вся последующая связь с KDC будет шифроваться с помощью сеансового ключа. Как ивсе другие сеансовые ключи, он имеет временный характер и действителен до истечениясрока действия билета TGT, либо до выхода пользователя из системы. По этой причинетакой ключ называют сеансовым ключом регистрации (logon session key). С точки зренияклиента, билет TGT почти ничем не отличается от обычного. Перед подключением к любойслужбе, клиент, прежде всего, обращается в кэш-память удостоверений и достает оттудасеансовый билет для этой службы. Если его нет, он начинает искать в этой же кэш-памятибилет TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключрегистрации и готовит с его помощью аутентификатор, который вместе с TGT высылаетв KDC. Одновременно туда направляется запрос на сеансовый билет для требуемой службы.Другими словами, организация безопасного доступа к KDC ничем не отличается от организациитакого доступа к любой другой службе домена — она требует сеансового ключа, аутентификатораи билета (в данном случае TGT). С точки же зрения службы KDC, билеты TGT позволяютускорить обработку запросов на получение билетов, сэкономив несколько наносекундна пересылке каждого из них. Центр распределения ключей KDC обращается к долговременномуключу пользователя только один раз, когда предоставляет клиенту первоначальный билетTGT. Во всех последующих транзакциях с этим клиентом центр KDC расшифровывает билетыTGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключрегистрации, который использует для проверки подлинности аутентификатора клиента.
Аутентификация за пределами домена
Функции центра KDC можно разделить на две категории: службу аутентификации,в задачу которой входит генерация билетов TGT, и службу выдачи билетов, создающуюсеансовые билеты. Такое разделение труда позволяет применять протокол Kerberos иза пределами его «родного» домена. Клиент, получивший билет TGT из службыаутентификации одного домена, может воспользоваться им для получения сеансовых билетовв службах выдачи билетов других доменов.
Чтобы лучше понять принцип междоменной аутентификации, рассмотримдля начала простейшую сеть, содержащую всего два домена — «Восток» и«Запад». Предположим, что администраторы этих доменов являются сотрудникамиодной организации или у них есть какие-либо другие веские причины уравнять пользователейвторого домена со своими собственными. В любом из этих случаев наладить аутентификациюмежду доменами нетрудно, для этого достаточно договориться о едином междоменномключе (в Windows 2000 такой ключ генерируется автоматически, когда между доменамиустанавливаются доверительные отношения). Как только ключ создан, служба выдачибилетов каждого домена регистрируется в центре KDC другого домена в качестве главногоабонента безопасности. В результате служба выдачи билетов каждого из доменов начинаетрассматривать службу выдачи билетов второго домена, как еще одну свою службу. Благодаряэтому клиент, прошедший аутентификацию и зарегистрировавшийся в системе, может запрашиватьи получать сеансовые билеты для нее.
А теперь рассмотрим, что происходит, когда пользователь с учетнойзаписью в домене «Восток» запрашивает доступ к серверу из домена«Запад». Прежде всего, клиент 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 ServiceExchange (обмен со службой выдачи билетов) или 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, который был получен с помощью подпротокола ASExchange, а также имя службы, на доступ к которой нужен билет.
/>
Рисунок.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 это — сетевой протокол аутентификации, позволяющий безопаснопередавать данные через незащищённые сети для безопасной идентификации. Также являетсянабором бесплатного ПО от Массачусетского технологического института (MassachusettsInstitute of Technology (MIT)), разработавшего этот протокол. Её организация направленав первую очередь на клиент-серверную модель и обеспечивает взаимную аутентификацию- оба пользователя через сервер подтверждают личности друг друга. Сообщения, отправляемыечерез протокол Kerberos, защищены от прослушивания и атак повторного воспроизведения.
Kerberos является одним из вариантов протокола Нидхема-Шрёдера,основан на симметричной криптосистеме и требует третье доверенное лицо (сервер).Расширение Kerberos позволяет использовать открытые ключи в процессе аутентификации.
Список использованных исочников
1. По материалам ресурса ru.wikipedia.org/wiki/Kerberos
2. По материалам ресурса www.oszone.net/4188_4/Kerberos