Kerberos

Dear MIT Kerberos & Internet Trust (KIT) Consortium Members,

We are writing today to provide an update on the status of the MIT KIT Consortium and to announce plans and paths forward for future activities.

Since its founding in 2007, the consortium has enjoyed great success, establishing Kerberos as one of the Internet's standard security protocols and enhancing the MIT Kerberos reference implementation with thousands of improvements. With the ensuing scope expansion and associated rebranding as the MIT Kerberos and Internet Trust Consortium (KIT), the consortium has likewise seen success researching and championing new digital identity standards.

As these dual-streams of work have progressed, it has become clear that there is a need for changing how we organize our work around these two activities to provide greater focus on both the long-term maintenance of the widely used MIT Kerberos implementation and the exploration of up-and-coming research activities in the area of digital identity. To that end, we are pleased to announce the following updates:

  • Going forward, MIT will operate MIT Kerberos development and maintenance as an Institute-funded open source project and will no longer seek external funding for these activities.  MIT will continue to publish releases of the MIT Kerberos distribution on a yearly basis, with discussion and contributions welcome via the kerberos@mit.edu and krbdev@mit.edu mailing lists.

  • Research related to Internet Trust protocols and development will occur under the auspices of MIT's recently established Institute for Data, Systems, and Society (IDSS).  IDSS will continue to seek sponsors looking to partner with MIT on developing frameworks and systems that address current challenges in Internet privacy and security, working closely with MIT faculty and students performing cutting-edge research in these areas.

Correspondingly, the MIT KIT name will be retired.  Kerberos development activity will occur via the kerberos.org project, and the work of developing new frameworks and systems that address current challenges in Internet privacy and security will be coordinated via the soon-to-be-launched MIT Internet Trust Consortium (http://trust.mit.edu), in IDSS.

It is our hope that these changes will allow MIT's and the world's investment in Kerberos to continue to flourish in the future, while simultaneously paving the way for MIT and its industry partners to continue to lead the way in tackling new challenges in the areas of Internet privacy and security.

John Charles
Vice President, MIT Information Systems & Technology
jcharles@mit.edu

Alex P. Pentland
Toshiba Professor, MIT
pentland@mit.edu

Kerberos: Сторожевой пёс Эфира
Автор: (C) 2002 Raj Shekhar
Перевод: (C) 2003 Юрий Прушинский


Вступление

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

Секретность
Секретность связана с сокрытием информации от любопытных глаз посторонних людей.
Идентификация
Идентификация связана с определением подлинности вашего партнера по общению, т.е. действительно ли он тот за кого себя выдает.
Проверка подлинности
Проверка подлинности информации связана с подписями: в её задачу входит однозначное определение отправителя файла или сообщения. Например, как вы сможете доказать, что получили заказ на 10 миллионов ботинок на левую ногу, когда их заказчик утверждает, что он заказал 10 штук на правую ногу!
Проверка целостности
Проверка целостности гарантирует, что ваша жизненно важная информация не была искажена в процессе передачи. Проверки такого рода наиболее важны при организации коммерческой деятельности в Интернете. Без обеспечения целостности и сохранности информации могут быть искажены заказы на поставки, контракты или заказы на покупку ценных бумаг, что может привести к катастрофическим последствиям.

Необходимость в идентификации

Для чего нам могут понадобится службы идентификации? Служба идентификации проверяет подлинность партнера по общению, поэтому идентификация является фундаментальным блоком при построении безопасного сетевого окружения. Если сервер совершенно точно идентифицирует своего клиента, то он знает, имеет ли тот право на доступ к соответствующим сервисам (например, печати) или нет, или на получение особых привилегий и т.п. Следует также различать понятия идентификация и авторизация. Если пользователь Foo говорит «удалить файл bar», то здесь процесс проверки того, что эту команду выполнил пользователь Foo называется идентификацией. А вот процесс проверки наличия у пользователя Foo прав на удаление файла bar называется авторизацией.

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

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

Введение в Kerberos

Kerberos был разработан в Массачусетском Технологическом Институте как средство для обеспечения сетевой безопасности. Своими корнями он уходит в проект «Афина», начатый ещё в 1983г. Его целью было создание высокоскоростной вычислительной сети в среде высокопроизводительных графических рабочих станций и серверов разных типов. При этом проект использовал Kerberos в качестве своей системы идентификации. Название Kerberos было заимствовано из греческой мифологии, в которой Kerberos — имя трёхголового пса, охраняющего врата в Гадес (подземное царство теней — прим.перев.). Протокол Kerberos использует настолько сильную систему шифрования, что клиент может идентифицироваться сервером (и наоборот) даже при небезопасном сетевом соединении. После того как клиент и сервер пройдут процедуру взаимной идентификации посредством Kerberos, они смогут шифровать весь свой трафик для обеспечения безопасности и целостности данных.

Цитата с http://web.mit.edu/Kerberos/www/

Большинство протоколов, использующихся в Интернете, не обеспечивают какой-либо безопасности вообще. Это привело к тому, что системными взломщиками в сети очень широко применяются «сниферы» паролей. Таким образом, любое приложение, отправляющее пароль в незашифрованном виде очень уязвимо. Хуже того, многие клиент-серверные приложения полагаются на «честность» клиентской программы и личность пользователя, использующего её. Другие же приложения полагаются на то, что клиенты сами будут контролировать дозволенность своих действий, без какой-либо проверки со стороны сервера.

Основной реализацией и структурой Kerberos от первой до четвёртой версий занимались двое бывших участников проекта «Афина», Стив Миллер из Digital Equipment Corporation, и Клиффорд Ньюман (сейчас работает в Институте Информационных Наук Университета Южной Калифорнии), а также Джером Салтцер, технический директор проекта «Афина», и Джеффри Шиллер, администратор сети университетского городка MIT. Кроме этого, другие участники проекта «Афина» тоже приложили усилия к развитию Kerberos. Последняя версия Kerberos 4 имеет patch level 10, и официально объявлена MIT «мертвой», вся дальнейшая работа сосредоточена вокруг Kerberos 5, последняя версия 1.2.1.

Для начала немного терминологии

Искусство создания шифров принято называть криптографией (cryptography), а их взлом — криптоанализом (cryptanalysis). Всё вместе это называется криптологией (cryptology). Сообщение, подлежащее шифрованию, называют открытым, или не зашифрованным текстом (plaintext or cleartext). Открытый текст шифруется по функции, параметром которой является ключ (key). Всё, что получается на выходе процесса шифрования, называется шифрованным текстом (ciphertext). Когда шифрованный текст проходит через функцию декодирования (decryption function), то мы получаем обратно открытый текст. Возвращаясь к нашей истории Алисы и Боба, то их (Алису и Боба) можно назвать участниками сессии (principals), главными персонажами этой истории.

Ключ шифрования иногда ещё называют ключом дешифрования, что то же самое. Этот ключ известен только доверителям. Его ещё называют разделяемый секретный ключ (shared secret key). Но тем не менее, в криптосистеме, предложенной Диффи и Хелманом (исследователи из Стэнфордского Университета) в 1976г., ключ шифрования и ключ дешифрования — разные вещи. Ключ, используемый для шифрования, становится публичным, таким образом сообщения, посылаемые владельцу этого ключа шифруются при помощи публичного ключа. Такой ключ называется открытым ключом (public key). Также, каждый пользователь имеет свой личный ключ (private key), известный только самому пользователю, и использующийся для дешифрации сообщений, получаемых пользователем. В отличие от криптографии с разделяемым ключом, такая система называется криптографией с открытым ключом (public-key cryptography). Алгоритм RSA является примером криптографии с открытым ключом. [Или алгоритмом шифрования с ассиметричным ключом. Прим.ред.]

И ещё чуть-чуть …

Перед тем как описывать процесс идентификации, необходимо избавиться от неопределенности и двусмысленности в используемых терминах.

Довольно часто сетевые приложения реализованы из двух частей:

  • часть, которая запрашивает сервис, называется клиентской стороной приложения
  • часть, которая предоставляет сервис, называется серверной стороной приложения

В известном смысле, каждый объект, использующий систему Kerberos, является клиентом. Чтобы различать между клиентом Kerberos и клиентом службы, клиент, использующий службу Kerberos, называется клиентом Kerberos (Kerberos client). Термин сервер приложения (application server) обозначает серверную часть приложения, к которой обращаются клиенты, прошедшие идентификацию по Kerberos.

Kerberos — это доверенная сторонняя система идентификации (third party authentication system). Доверенная в том смысле, что каждый клиент доверяет тому, с какой точностью Kerberos идентифицирует всех клиентов. Чтобы доказать серверу приложения, что Kerberos-клиент проверен Kerberos-сервером, он использует квитанцию (ticket). Квитанция необходима для того чтобы Kerberos-клиент смог воспользоваться любым сервером приложения. Сервер проверяет квитанцию, чтобы удостовериться в том, что пользователь идентифицирован. Если проверка пройдена, то запрос клиента принимается. Наряду с квитанцией, в Kerberos для подтверждения личности клиента применяются удостоверения (authenticator). Удостоверение содержит дополнительную информацию, которая при сравнении подтверждает то, что клиент, предоставляющий квитанцию, является именно тем, кому эта квитанция была действительно выдана.

Kerberos ведёт базу данных своих клиентов и их личных ключей для идентификации. Из-за того, что Kerberos «знает» эти личные ключи, он может создавать сообщения, по которым один клиент может быть уверен в подлинности другого. Разработчики и не ожидают того, что весь мир будет доверять единой базе данных, поэтому они предусмотрели использование различных зон (realms). Зона — это административный объект, предоставляющий идентификационные данные.

Любая организация, желающая иметь собственный Kerberos-сервер, организует свою «зону»

Переходим к деталям

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

  • Пароли по сети никогда не отсылаются открытым текстом, они всегда шифруются. Кроме того, они не хранятся в открытом виде ни у Kerberos-клиентов, ни на сервере.
  • Каждый клиент имеет свой пароль, т.е. пароль есть у каждого сервера приложений, пользователя и Kerberos-клиента.
  • Единственный объект, который знает все пароли — это Kerberos-сервер, который находится в достаточной физической безопасности.

И клиент, и сервер приложения обязаны зарегистрировать свои ключи на сервере идентификации (СИ). Если клиент — это пользователь, то его ключ определяется паролем, который он выбирает. Для службы (например, демон печати) ключом является случайно сгенерированное значение. Все эти ключи устанавливаются в процессе регистрации клиентов.

Процесс идентификации происходит следующим образом:

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

    Для чего же ставится «метка дата создания». Эта метка необходима для того, чтобы не допустить кому-либо скопировать квитанцию и позднее сымитировать Kerberos-клиента. Этот возможный тип атаки известен как воспроизведение (replay). Из-за того, что часы не всегда работают идеально синхронно, дается небольшая отсрочка (около пяти минут) между меткой даты\времени и текущим временем.

  2. СИ отвечает мандатом (квитанция и ключ сессии), зашифрованным ключом клиента. Также СИ вставляет в мандат своё имя, чтобы удостоверить Kerberos-клиента в том, что дешифрация была им [CИ] успешно выполнена и что данное сообщение пришло от сервера.

    СИ не знает, действительно ли клиент является инициатором (principal) запроса на квитанцию. Он просто отвечает на запросы, не зная и не заботясь о том, что они одинаковые. Это вполне допустимо, потому что никто кроме Kerberos-клиента, чья личность была указана в запросе, не сможет воспользоваться ответом. Ко всему прочему эта информация шифруется ключом инициатора запроса.

  3. Kerberos-клиент дешифрует мандат при помощи своего ключа для того, чтобы в свою очередь получить ключ сессии. Здесь необходимо учесть, что из-за того, что квитанция шифруется ключом сервера приложения, Kerberos-клиент не может расшифровать его [ключ сессии].
  4. Чтобы получить доступ к серверу приложения, Kerberos-клиент строит идентификатор, содержащий имя клиента, его ip-адрес и текущее время. Затем этот идентификатор шифруется ключом сессии, который был получен с квитанцией для сервера, и отсылается вместе с квитанцией серверу.
  5. Служба дешифрует эту квитанцию своим ключом, получает ключ сессии и личность Kerberos-клиента, которые сервер указал в квитанции. Затем она открывает идентификатор ключом сессии, и таким образом по идентификатору и квитанции служба получает представление о личности клиента.
  6. Ключ сессии (теперь уже известный клиенту и серверу приложения) используется для идентификации клиента, и в свою очередь, может идентифицировать сервер. Более того, его можно применять для последующего шифрования коммуникаций двух сторон или обмена отдельными суб-сессионными ключами, шифрующими последующие переговоры.

Предоставляемая квитанциия

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

Kerberos (protocol)

Если Kerberos-клиентом будет пользователь, то его несомненно будет раздражать, если он будет каждый раз вводить пароль, чтобы распечатать файл или, если он захочет изменить файл по сети (помните что ключ получается из пароля пользователя?). Наиболее простое решение этой проблемы — кеширование ключей, полученных из пользовательских паролей. Но кеширование ключей опасно. При помощи копии ключа, злоумышленник может имитировать пользователя любое время (до первой смены пароля).

Для решения этой проблемы в Kerberos присутствует специальный агент, называющийся сервером предоставления квитанций (СПК). Несмотря на то, что СПК и СИ могут физически располагаться на одной машине, логически они отличаются друг от друга (в паре их часто называют Центром Распределения Ключей — ЦРК). Функция СПК состоит в следующем: перед тем как получить доступ к любой службе, пользователь запрашивает квитанцию у СПК. Обычно это происходит при входе пользователя в систему. Такая квитанция называется предоставляемой квитанцией (ПК) (ticket granting ticket — TGT). После получения ПК, в любой момент обращения пользователя к любой службе, он запрашивает квитанцию не у СИ, а у СПК. Далее, ответ шифруется уже не секретным ключом пользователя, а ключом сессии, который СИ предоставляет СПК. В этот ответ вкладывается новый ключ сессии для использования службой. Последующий обмен происходит как было описано выше. Следует отметить, что СПК удобно использовать только на короткий период, примерно на восемь часов.

Межзональная идентификация

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

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

Таким образом, квитанции, созданные удаленным СПК сообщают конечной службе о том, что клиент был идентифицирован из другой зоны.

Заключение

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

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

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

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

Raj Shekha

Я получил степень Бакалавра Информационных Технологий в Университете Дели. Стал фанатом Линукс с тех пор как прочитал книгу Ричарда Стивенса «Сетевое Программирование в UNIX», и сам начал заниматься программированием под Линукс в седьмом семестре. Также пытаюсь увлечь этим людей, с которыми приходится сталкиваться.

Мой адрес в Сети http://geocities.com/lunatech3007.


Copyright (c) 2002, Raj Shekhar.

Другим методом аутентификации, основанным на использовании секретного идентификатора, является протокол Kerberos. Протокол Kerberos был создан более десяти лет назад в Массачусетском технологическом институте в рамках проекта Athena. Однако общедоступным этот протокол стал, начиная с версии 4, а версия 5 была принята в качестве стандарта IETF. Требования реализации протокола изложены в документе RFC 1510, кроме того, в спецификации RFC 1964 описывается механизм и формат передачи мандатов (билетов) безопасности в сообщениях Kerberos.

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

Основная концепция протокола Kerberos заключается в возможности взаимного удостоверения взаимодействующих сторон при помощи разделяемого между ними общего секрета.

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

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

Kerberos: The Network Authentication Protocol

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

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

8).

  1. Пользователь оправляет сообщения на Kerberos-сервер включающее имя и аутентификатор, зашифрованный, при помощи разделяемого ключа, и содержащий структуру данных с двумя полями: имя и текущее время пользователя.
  2. Сервер дешифрует полученный аутентификатор, если операция успешна, то пользователь является именно тем за кого себя выдает.
  3. После дешифрования сервер сравнивает время из аутентификатора с локальным временем, если их разница приемлема, то сервер точно решает, что сообщение послано легальным пользователем.
  4. Для обеспечения аутентификации сервера, он создает новый аутентификатор содержащий только зашифрованное время, полученное от пользователя и отсылает его обратно.
  5. Пользователь дешифрует полученный аутентификатор и сравнивает время. Если процесс дешифрации успешен и времена совпадают, значит, сервер именно тот с которым хотел взаимодействовать пользователь.

Рис.

8. Схема реализации взаимной аутентификации в протоколе Kerberos

 

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

Для решения проблемы управления ключами Kerberos использует дополнительное звено-посредник – центр распределения ключей (Key Distribution Center, KDC). KDC представляет собой службу, работающую на физически защищённом сервере. Она ведёт базу данных с информацией об учётных записях всех главных абонентов безопасности своей области. Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Этот ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи генерируются на основе пароля пользователя, указываемого при входе в систему.

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

Рис. 9. Схема работы KDC

 

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

Необходимо отметить, что серверное программное обеспечение должно быть адаптировано (его обычно называют керберезированным) для работы с протоколом Kerberos.


Дата добавления: 2014-01-04; Просмотров: 344; Нарушение авторских прав?;




Читайте также:


[Страница назад | Страница вперед | Содержание | Индекс | Библиотека | Юридическая информация | Поиск]

Руководство по установке


Приложение D. Установка Kerberos версии 5

Для установки пакета Kerberos V5 выполните следующие действия:

  • Если вам нужно программное обеспечение клиента, установите набор файлов bos.security.krb5.client
  • Если вам нужно программное обеспечение сервера, установите набор файлов bos.security.krb5.server
  • Если вам нужен полный пакет, установите bos.security.krb5

Во избежание конфликтов имен между командами DCE и Kerberos (т.е. между командами klist, kinit и kdestroy), команды Kerberos устанавливаются в каталогах /usr/krb5/bin и /usr/krb5/sbin. Вы можете добавить эти каталоги в переменную PATH. Если вы этого не сделаете, то вам придется вводить полные пути к командам Kerberos.


Настройка серверов KDC и kadmin Kerberos V5

Примечания:

  1. Устанавливать программное обеспечение серверов DCE и Kerberos в одной физической системе не рекомендуется. Если же это необходимо, то вы должны изменить стандартные номера портов Internet по умолчанию либо для клиентов и сервера DCE, либо для клиентов и сервера Kerberos. В обоих случаях такое изменение может повлиять на взаимодействие с уже установленными средствами DCE и Kerberos.
  2. В Kerberos V5 по умолчанию настроено отклонение запросов на выдачу паспортов, если они поступают от хостов, системное время которых отличается от времени сервера на больший интервал, чем допускается Контроллером домена Kerberos (KDC). По умолчанию отклонение не должно превышать 300 секунд (пяти минут). В Kerberos обязательна синхронизация времени сервера и клиентов в той или иной форме.

    Для синхронизации времени рекомендуется применять демон xntpd или timed. Например, вы можете настроить синхронизацию с помощью демона timed следующим образом:

    1. Настройте сервер KDC в качестве сервера времени, запустив демон timed. # timed -M
    2. Запустите демон timed на каждом клиенте Kerberos. # timed -t

Для настройки серверов KDC и kadmin Kerberos запустите команду mkkrb5srv. Для обеспечения взаимодействия пакета Kerberos с существующими средствами защиты выполните команду mkkrb5srv со следующими параметрами:

mkkrb5srv -r область -s сервер -d домен

Пример:

Для настройки пакета Kerberos в области на сервере в домене введите следующую команду:

mkkrb5srv -r UD3A.AUSTIN.IBM.COM -s sundial.austin.ibm.com \ -d austin.ibm.com

Примечание: Запуск kadmind и krb5kdc из каталога /etc/inittab произойдет спустя несколько минут.

Команда выполняет следующую последовательность операций:

  1. Создает файл /etc/krb5/krb5.conf. Значения области, административного сервера Kerberos и имени домена будут взяты из командной строки. Кроме того, команда обновляет пути к файлам протокола default_keytab_name, kdc и kadmin.
  2. Создает файл /var/krb5/krb5kdc/kdc.conf. Эта команда задает значение для kdc_ports, а также пути к имени базы данных, admin_keytab, acl_file, dict_file, key_stash_file и значения для kadmin_port, max_life, max_renewable_life, master_key_type и supported_enctypes.
  3. Создает файл /var/krb5/krb5kdc/kadm5.acl. Команда настраивает управлением доступом для субъектов администратора, пользователя root и хоста.
  4. Создает базу данных и один субъект администратора. Вам будет предложено задать главный ключ Kerberos, а также задать имя и пароль для идентификации субъекта администратора Kerberos. Важно, чтобы главный ключ и имя и пароль субъекта администратора хранились в надежном месте на случай восстановления после сбоя.

Если вы испытываете затруднения, обратитесь к разделам Примеры выполнения и Сообщения об ошибках и действия по исправлению.


Настройка клиентов Kerberos V5

По окончании установки обычные пользователи не смогут не заметить, что в системе применяется технология Kerberos. Несмотря на то, что процесс входа в систему остался без изменений, существует побочный эффект, заключающийся в том, что теперь с процессами пользователей будут связаны начальные паспорта (TGT) Kerberos. Для настройки Kerberos в качестве основного средства идентификации пользователей в системах выполните команду mkkrb5clnt со следующими параметрами:

mkkrb5clnt -c KDC -r область -s административный сервер -d домен -A \ -i база_данных -K -T

Пример:

mkkrb5clnt -c sundial.austin.ibm.com -r UD3A.AUSTIN.IBM.COM \ -s sundial.austin.ibm.com -d austin.ibm.com \ -A -i расположение_файлов -K -T

Эта команда выполняет следующие действия:

Создает файл /etc/krb5/krb5.conf.

Значения области, административного сервера Kerberos и имени домена будут взяты из командной строки. Кроме того, команда обновляет пути к файлам протокола default_keytab_name, kdc и kadmin.

Так как задан флаг -i, команда настраивает полностью интегрированный вход в систему. Значение расположение_файлов указывает расположение субъектов Kerberos.

Так как задан флаг -K, команда настраивает Kerberos в качестве схемы идентификации по умолчанию. Это позволяет идентифицировать пользователей с помощью Kerberos в момент их входа в систему.

Флаг -A добавляет в базу данных Kerberos инструкцию о назначении пользователя root администратором Kerberos.

Флаг -T указывает, что следует принять основанный на TGT паспорт администратора сервера.

При установке системы в домене DNS, отличном от домена KDC, необходимо выполнить следующие дополнительные действия:

  1. Добавьте новую запись после [domain realm] в файле /etc/krb5/krb5.conf.
  2. Отобразите другой домен в свою область.

Например, если вы хотите добавить хост в свою область , добавьте в файл /etc/krb5/krb5.conf следующую запись:

[domain realm] .pok.ibm.com = UD3A.AUSTIN.IBM.COM


Сообщения об ошибках и действия по исправлению

Ниже перечислены ошибки, которые могут произойти при выполнении команды mkkrb5srv:

  • Если файл krb5.conf, kdc.conf или kadm5.acl уже существует, то команда оставит значения без изменения. Будет выдано предупреждающее сообщение о том, что файл уже существует. Любые значения конфигурации можно изменить, отредактировав файл krb5.conf, kdc.conf или kadm5.acl.
  • Если вы ошибетесь при вводе и база данных создана не будет, удалите созданные файлы конфигурации и выполните команду повторно.
  • Если база данных несовместима со значениями конфигурации, удалите базу данных в /var/krb5/krb5kdc/* и выполните команду повторно.
  • Убедитесь, что в вашей системе запущены демоны Make sure kadmind и krb5kdc. Для этого воспользуйтесь командой ps. Если запустить демоны не удается, просмотрите файл протокола.

Ниже перечислены ошибки, которые могут произойти при выполнении команды mkkrb5clnt:

  • Неправильные значения в файле krb5.conf можно исправить, отредактировав файл /etc/krb5/krb5.conf.
  • Неправильные значения для флага -i можно исправить, отредактировав файл /usr/lib/security/methods.cfg.

Создаваемые файлы

Команда mkkrb5srv создает следующие файлы:

  • /etc/krb5/krb5.conf
  • /var/krb5/krb5kdc/kadm5.acl
  • /var/krb5/krb5kdc/kdc.conf

Команда mkkrb5clnt создает следующие файлы:


Примеры выполнения

Ниже приведен пример вывода при выполнении команды mkkrb5srv:

Набор файлов Уровень Состояние Описание —————————————————————————- Путь: /usr/lib/objrepos bos.security.krb5.server 5.1 ЗАФИКСИРОВАНО Сервер сетевой идентификации (служба конфиденциальности) Путь: /etc/objrepos bos.security.krb5.server 5.1 ЗАФИКСИРОВАНО Сервер сетевой идентификации (служба конфиденциальности) Создается /etc/krb5/krb5.conf Создается /var/krb5/krb5kdc/kadm5.acl Создается /var/krb5/krb5kdc/kdc.conf Инициализируется база данных ‘/var/krb5/krb5kdc/principal’ для области ‘UD3A.AUSTIN.IBM.COM’ имя главного ключа ‘K/M@UD3A.AUSTIN.IBM.COM’ Вам будет предложено указать Главный пароль к базе данных. Вы должны ЗАПОМНИТЬ этот пароль.

Идентификация и аутентификация. Протокол Kerberos

Введите главный ключ к базе данных KDC: Еще раз введите главный ключ к базе данных KDC для контроля: Идентификация субъекта root/admin@UD3A.AUSTIN.IBM.COM с паролем. ПРЕДУПРЕЖДЕНИЕ: стратегия для admin/admin@UD3A.AUSTIN.IBM.COM не задана; по умолчанию принимается отсутствие стратегии Введите пароль для субъекта «admin/admin@UD3A.AUSTIN.IBM.COM»: Еще раз введите пароль для субъекта «admin/admin@UD3A.AUSTIN.IBM.COM»: Субъект «admin/admin@UD3A.AUSTIN.IBM.COM» создан. Идентификация субъекта root/admin@UD3A.AUSTIN.IBM.COM с паролем.

Ниже приведен пример вывода при выполнении команды mkkrb5clnt:

Создается /etc/krb5/krb5.conf Пароль admin/admin@UD3A.AUSTIN.IBM.COM: Настройка полностью интегрированного входа в систему Идентификация субъекта admin/admin с существующим одноразовым разрешением. ПРЕДУПРЕЖДЕНИЕ: стратегия для host/diana@UD3A.AUSTIN.IBM.COM не задана; по умолчанию принимается отсутствие стратегии Субъект «host/diana@UD3A.AUSTIN.IBM.COM» создан. Одноразовое разрешение администратора НЕ УНИЧТОЖЕНО.

Идентификация субъекта admin/admin с существующим одноразовым разрешением. Одноразовое разрешение администратора НЕ УНИЧТОЖЕНО. Идентификация субъекта admin/admin с существующим одноразовым разрешением. Субъект «kadmin/admin@UD3A.AUSTIN.IBM.COM» изменен. Одноразовое разрешение администратора НЕ УНИЧТОЖЕНО. Настройка Kerberos в качестве схемы идентификации по умолчанию Назначение пользователя root администратором Kerberos Идентификация субъекта admin/admin с существующим одноразовым разрешением. ПРЕДУПРЕЖДЕНИЕ: стратегия для root/diana@UD3A.AUSTIN.IBM.COM не задана; по умолчанию принимается отсутствие стратегии Введите пароль для субъекта «root/diana»: Еще раз введите пароль для субъекта «root/diana»: Субъект «root/diana@UD3A.AUSTIN.IBM.COM» создан. Одноразовое разрешение администратора НЕ УНИЧТОЖЕНО. Очистка одноразовых разрешений администратора и завершение работы.

Kerberos – это программный продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем.

Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты – пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.

Система Kerberos представляет собой доверенную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности.

Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило – клиент) посылает Kerberos запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, присланной клиентом.

9 — Протокол аутентификации Kerberos

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

Проиллюстрируем описанную процедуру.

 

Рис. 10.1. Проверка сервером S подлинности клиента C.

 

Здесь c и s – сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 – дополнительная (по отношению к билету) информация, Tc.s – билет для клиента C на обслуживание у сервера S, Kc и Ks – секретные ключи клиента и сервера, {info}K – информация info, зашифрованная ключом K.

Приведенная схема – крайне упрощенная версия реальной процедуры проверки подлинности. Более подробное рассмотрение системы Kerberos можно найти, например, в статье В. Галатенко «Сервер аутентификации Kerberos (Jet Info, 1996, 12-13). Нам же важно отметить, что Kerberos не только устойчив к сетевым угрозам, но и поддерживает концепцию единого входа в сеть.


Дата добавления: 2014-01-20; Просмотров: 117; Нарушение авторских прав?;




Читайте также:

Протокол аутентификации Kerberos

В Windows Server 2003 используется модифицированная пятая версия протокола – Kerberos v5. Для шифрования применяется алгоритм DES (стандарт шифрования данных). Протокол обеспечивает аутентификацию в открытых сетях, т. е. там, где передаваемые пакеты могут быть перехвачены и изменены. Преимуществом протокола Kerberos по сравнению с протоколом NTLM является то, что в процессе аутентификации сервер не только удостоверяет подлинность клиента, но и по требованию клиента подтверждает свою достоверность. Ещё одно преимущество – время аутентификации при использовании Kerberos меньше.

Термины, используемые в протоколе Kerberos

Шифрование (encryption) – процесс преобразования данных в такую форму, которая не может быть прочитана без процесса расшифрования.

Шифрование осуществляется с применением шифрующего ключа (encryption key), расшифрование использует расшифровывающий ключ (decryption key). Секретный ключ пользователя получается путем хеширования его пароля.

Хеширование (hashing) обозначает такое преобразование исходной последовательности данных, результат которого – хеш (hash), в отличие от результата шифрования, не может быть преобразован обратно в исходную последовательность.

Сеанс (session) – это период непрерывного соединения между двумя узлами (например, клиентом и сервером). В начале сеанса требуется пройти процедуру аутентификации.

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

клиент, сервер и посредник.

Клиент – компьютер , желающий получить доступ к ресурсам сервера. Предварительно клиент должен пройти процедуры аутентификации и авторизации, используя свое удостоверение.

Сервер – компьютер, предоставляющий ресурсы авторизованным клиентам.

Посредник – это специальный физически защищенный сервер, на котором работают две службы: 1 – центр распространения ключей (Key Distribution Center, KDC) и служба предоставления билетов (Ticket Granting Service, TGS). В сетях Active Directory этим сервером является контроллер домена.


Удостоверения (credentials) – специальные сетевые пакеты, используемые для взаимной идентификации клиента и сервера.

Удостоверения бывают двух видов: билеты (tickets) и аутентификаторы (authenticators).

Билет (ticket) – специальный пакет, удостоверяющий подлинность своего владельца. В состав билета входят имя владельца, сеансовый ключ и другие параметры. Период действия билета ограничен параметром, который называется время жизни (lifetime). По умолчанию время жизни равно 5 минутам.

Существует два типа билетов: билеты TGT (Ticket-Granting Ticket – билеты на выдачу билетов) и сеансовые билеты (session ticket). Билет TGT содержит учетные данные, выдаваемые пользователю центром распределения ключей KDC при входе пользователя в систему. Сеансовый билет требуется для установления сеанса соединения клиента с сервером.

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

Для дальнейшего изложения введем обозначения, представленные в

таблице. Обозначение Комментарий

AC Аутентификатор клиента

AS Аутентификатор сервера

KC Секретный ключ клиента

KS Секретный ключ сервера

{X}K Сообщение Х, зашифрованное ключом К

{AC}KC Аутентификатор клиента, зашифрованный секретным ключом клиента

КA,B Сеансовый ключ для соединения узлов А и В

KC,TGS Сеансовый ключ для соединения клиента и службы TGS

TGT Билет TGT

TC,S Сеансовый билет для соединения клиента и сервера

N Имя клиента

S Имя сервера

t Момент времени отправки сообщения

 

 

46. Этапы аутентификации: регистрация клиента.

Основные этапы аутентификации

Клиенту для получения доступа к ресурсам сервера предварительно требуется пройти проверку подлинности, т. е. аутентифицироваться. Процедура аутентификации состоит из трех основных этапов (рис. 9.2):

1) регистрация клиента;

2) получение сеансового билета;

3) доступ к серверу.

Этап регистрации клиента

При входе в систему под управлением Windows Server 2003 пользователь вводит имя своей учетной записи, пароль и указывает домен. Пароль при помощи хеширования преобразуется в секретный ключ клиента KC. Точно такой же ключ хранится в центре распределения ключей KDC и сопоставлен с данным пользователем. Клиент создает аутентификатор {AC}KC, зашифрованный с использованием ключа KC, и отсылает его центру распределения ключей (рис. 9.3).

Установка Kerberos в Ubuntu

Аутентификатор содержит информацию об имени клиента N и время отправки аутентификатора t.

Этап регистрации клиента

При входе в систему, пароль при помощи хеширования преобразуется в секретный ключ клиента KC. Точно такой же ключ хранится в центре распределения ключей KDC и сопоставлен с данным пользователем. Клиент создает аутентификатор {AC}KC, зашифрованный с использованием ключа KC, и отсылает его центру распределения ключей (рис. 9.3). Аутентификатор содержит информацию об

имени клиента N и время отправки аутентификатора t.

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

• {KC,TGS}KC – сеансовый ключ KC,TGS для связи клиента и службы TGS, зашифрованный ключом KC;

• {TGT}KTGS – билет на выдачу билетов TGT, зашифрованный ключом KTGS, известным только службе TGS.

Сеансовый ключ KC,TGS клиент в состоянии расшифровать, используя свой ключ KC, а расшифровка билета TGT клиентом невозможна, так как ключ KTGS ему неизвестен. Билет TGT в зашифрованном виде сохраняется в кэш-память клиента и при необходимости извлекается оттуда.

47. Этапы аутентификации: получение сеансового билета.

Предыдущая12345678910Следующая

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *