Аутентификация по протоколу Kerberos

Лаконичный обзор

В операционной системе Microsoft® Windows® 2000 аутентификация юзеров делается по дефлоту при помощи протокола Kerberos. Внедрение этого эталона делает надежную базу для взаимодействия меж разными платформами и при всем этом существенно увеличивает безопасность сетевой аутентификации.

В Windows 2000 применяется протокол Kerberos версии 5, дополненный расширениями, связанными с инфраструктурой открытых ключей. Безопасность системы обеспечивает клиент Kerberos при помощи интерфейса Security Support Provider Interface. Начальная проверка юзера делается в рамках процесса Winlogon, которая обеспечивает единую регистрацию юзеров в системе. Центр рассредотачивания ключей Key Distribution Center (KDC) Kerberos интегрирован с другими службами безопасности Windows 2000, установленными на контроллере домена. Учетные записи безопасности хранятся в базе данных службы каталогов Active Directory.

В реальном документе рассматриваются разные составляющие данного протокола и тщательно описывается его практическая реализация.

Введение

Реальный документ представляет технические нюансы реализации протокола аутентификации Kerberos 5 в операционной системе Microsoft® Windows® 2000. Тут приводится подробное описание важных концепций, строительных частей, также функций аутентификации по протоколу Kerberos. 1-ый раздел «Обзор протокола Kerberos» предназначен тем, кто не знаком с этим протоколом. Следующие разделы посвящены более подробному описанию того, как Microsoft воплотила Kerberos в операционной системе Windows 2000. Заканчивается информационный документ коротким обсуждением вопросов взаимодействия описываемого протокола с другими реализациями Kerberos.

Аутентификация в Windows 2000

Windows 2000 поддерживает несколько протоколов, которые позволяют убедиться в том, что входящий в систему юзер вправду имеет тут свою учетную запись. Посреди их – протоколы аутентификации удаленных подключений и протоколы аутентификации юзеров, входящих в сеть через Веб. Но снутри доменов Windows 2000 для проверки пользовательских данных предвидено два способа:

Kerberos версия 5. Протокол Kerberos 5 является стандартным средством аутентификации сетевых юзеров в домене Active Directory на всех компьютерах с операционной системой Windows 2000.
Windows NT LAN Manager (NTLM). Протокол NTLM применялся в качестве стандартного средства сетевой аутентификации в операционной системе Windows NT® 4.0. В среде Windows 2000 он употребляется для аутентификации серверов и доменов Windows NT 4.0. Не считая того, NTLM применяется для локальной аутентификации на автономных компьютерах, работающих под управлением Windows 2000.

Компы под управлением Windows 3.11, Windows 95, Windows 98 и 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, приводится ниже.

Более действенная аутентификация на серверах. При аутентификации по протоколу NTLM серверу приложений приходится подключаться к контроллеру домена при проверке каждого клиента. С Kerberos такая необходимость отпадает – тут аутентификация делается за счет проверки удостоверения, представленного клиентом. Личное удостоверение клиент получает от контроллера единожды, после этого может не один раз использовать его в протяжении всего сеанса работы в сети.
Обоюдная аутентификация. Протокол NTLM позволяет серверу идентифицировать собственных клиентов, но не предугадывает верификации сервера ни клиентами, ни другими серверами. Этот протокол разрабатывался для сетей, в каких все серверы числятся законными. В отличие от него, Kerberos такового допущения не делает, потому инспектирует обоих участников сетевого подключения, любой из которых в итоге может точно выяснить, с кем поддерживает связь.
Делегированная аутентификация. Когда клиент сети Windows обращается к ресурсам, службы операционной системы, сначала, создают его идентификацию. В почти всех случаях для выполнения этой операции службе довольно инфы на локальном компьютере. Как NTLM, так и Kerberos обеспечивают все данные, нужные для идентификации юзера на месте, но время от времени их бывает недостаточно. Некие распределенные приложения требуют, чтоб при подключении к серверным службам на других компьютерах идентификация клиента выполнялась локально службой самого этого клиента. Решить делему помогает Kerberos, где предусмотрен особый механизм представительских билетов, который позволяет на месте идентифицировать клиента при его подключении к другим системам. В протоколе NTLM такая возможность отсутствует.
Облегченное управление доверительными отношениями. Одно из принципиальных плюсов обоюдной аутентификации по протоколу Kerberos заключается в том, что доверительные дела меж доменами Windows 2000 по дефлоту являются двухсторонними и транзитивными. Благодаря этому в сетях с обилием доменов не придется устанавливать много очевидных доверительных отношений. Заместо этого все домены большой сети можно свести в дерево транзитивных отношений обоюдного доверия. Удостоверение, выданное системой безопасности для хоть какого домена, может приниматься во всех ветвях дерева. Если же сеть содержит несколько деревьев, то удостоверение хоть какого из их будет приниматься по всему «лесу».
Сопоставимость. В базу собственной реализации протокола Kerberos компания Microsoft положила стандартные спецификации, рекомендованные группой IETF. Благодаря такому подходу удалось обеспечить аутентификацию клиентов Windows 2000 во всех сетях, которые поддерживают Kerberos 5.

Эталоны аутентификации по протоколу Kerberos

Протокол Kerberos был сотворен в Массачусетском технологическом институте в рамках проекта Athena[1]. Но общедоступным этот протокол стал только после возникновения версии 4. После того, как спецы отрасли исследовали новый протокол, его создатели разработали и предложили юзерам еще одну версию – Kerberos 5, которая и была принята в качестве эталона IETF. Реализация протокола в Windows 2000 выполнена в серьезном согласовании с требованиями, изложенными в документе RFC 1510[2]. Не считая того, при ее разработке были применены механизм и формат передачи контекстов безопасности в сообщениях Kerberos, описанные в спецификациях Веба из документа RFC 1964[3].

Расширения протокола Kerberos

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

Обзор протокола Kerberos

Протокол аутентификации Kerberos предлагает механизм обоюдной идентификации клиента и сервера (либо 2-ух серверов) перед установлением связи меж ними. В протоколе учтено, что исходный обмен информацией меж клиентами и серверами происходит в открытой среде, а пакеты, передаваемые по каналам связи, могут быть перехвачены и изменены. Другими словами, протокол предназначен для работы в среде, которая очень припоминает нынешний Веб. Тут злодей просто может имитировать запросы клиента либо сервера, перехватывать связь меж законными клиентами и серверами, даже искажать передаваемую информацию.

Главные концепции

Протокол Kerberos интенсивно употребляет технологии аутентификации, опирающиеся на «секреты для двоих». Основная концепция достаточно ординарна: если есть секрет, узнаваемый только двоим, хоть какой из его хранителей может просто удостовериться, что имеет дело конкретно со своим напарником. Для этого ему довольно любым методом проверить, знает ли собеседник их общий секрет.

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

Сейчас Бобу и Алисе остается только решить, каким образом показать свое познание пароля. Можно, скажем, просто включить его в текст сообщения, к примеру, после подписи: «Alice, Our$ecret». Это было бы до боли просто, комфортно и накрепко, если б Алиса и Боб были убеждены, что никто другой не читает их сообщений. Но почта передается по сети, где работают и другие юзеры, а посреди их есть Кэрол, которая очень любит подключать к сети собственный анализатор пакетов в надежде выведать чьи-нибудь секреты. И становится совсем ясно, что Алиса не может просто именовать пароль в тексте письма. Чтоб секрет оставался секретом, о нем нельзя гласить открыто, необходимо отыскать метод только сообщить собеседнику, что он для тебя известен.

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

Аутентификаторы

Обычный протокол аутентификации с скрытым ключом вступает в действие, когда кто-нибудь стучится в сетевую дверь и просит впустить его. Чтоб обосновать свое право на вход, юзер предъявляет аутентификатор (authenticator) в виде блока инфы, зашифрованного при помощи секретного ключа. Содержание этого блока должно изменяться при каждом следующем сеансе, в неприятном случае злодей полностью может просочиться в систему, воспользовавшись перехваченным сообщением. Получив аутентификатор, привратник расшифровывает его и инспектирует полученную информацию, чтоб убедиться в удачливости расшифрования. Если все прошло нормально, страж может быть уверен, что человеку, предъявившему аутентификатор, известен скрытый ключ. А ведь этот ключ знают всего двое, при этом какой-то из них – сам привратник. Таким макаром, он делает вывод, что вторженец вправду тот человек, за которого себя выдает.

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

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

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

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

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

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

3.    Боб шифрует время из сообщения Алисы с их помощью общего ключа и включает его в собственное сообщение, которое направляет Алисе.

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

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

Аутентификация по протоколу Kerberos

Рис. 1. Обоюдная аутентификация (Алиса-Боб)

Управление ключами

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

Само заглавие протокола Kerberos гласит о том, как тут решена неувязка управления ключами. Кербер (либо Цербер) – персонаж традиционной греческой мифологии. Этот злобный пес о 3-х головах, по поверьям греков, охраняет врата подземного королевства мертвых. Трем головам Кербера в протоколе Kerberos соответствуют три участника неопасной связи: клиент, сервер и доверенный посредник меж ними. Роль посредника тут играет так именуемый центр рассредотачивания ключей Key Distribution Center  или, сокращенно, KDC.

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

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

Аутентификация по протоколу Kerberos

Рис. 2. Управление ключами (в теории)

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

Сеансовые билеты

В ответ на запрос клиента, который хочет подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту, как показано на рис. 3. Сообщение, предназначенное клиенту, шифруется средством длительного ключа клиента, а сеансовый ключ для сервера вкупе с информацией о клиенте вкладывается в блок данных, получивший заглавие сеансового билета (session ticket). Потом сеансовый билет полностью шифруется при помощи длительного ключа сервера, который знают только служба KDC и данный сервер. После чего вся ответственность за обработку билета, несущего внутри себя зашифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер.

Аутентификация по протоколу Kerberos

Рис. 3. Управление ключами (на практике)

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

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

Аутентификация по протоколу Kerberos

Рис. 4. Обоюдная аутентификация (клиент-сервер)

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

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

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

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.