Kerberos — проверенный временем стандарт безопасности с открытым кодом, однако не помешают ли проблемы взаимодействия успеху реализации, предложенной Microsoft?
Сторожевые псы незаменимы для охраны дома или военной базы. Но если речь идет о защите узлов компьютерной сети, то вам придется подыскать что-то другое (попробуйте «инсталлировать» немецкую овчарку).
Впрочем, одна «собачка» все же способна помочь вам в деле обеспечения компьютерной безопасности. Протокол аутентификации Kerberos позволяет клиентам и серверам с высокой степенью надежности удостоверять «личность» друг друга перед установлением сетевого соединения. Протокол был разработан в Массачусетском технологическом институте (MIT) в конце 1980-х гг. и получил свое название по имени трехголового пса Цербера из греческой мифологии, охранявшего вход в Аид. Однако сегодня Kerberos стоит не на страже подземного царства, а на защите распределенной компьютерной среды, в которой каждый компьютер имеет доступ к ресурсам любого другого узла сети.
Пол Хилл, старший программист информационных систем MIT и участник группы разработки Kerberos с 1992 г., отмечает следующие преимущества системы. Во-первых, она уже свыше десяти лет выставлена на всеобщее обозрение. Во-вторых, пятая версия протокола — самая актуальная на сегодняшний день — разрабатывалась в рамках процесса стандартизации IETF. Наконец, Kerberos обеспечивает безопасную аутентификацию и целостность сообщений, а также конфиденциальность данных и взаимопроверку клиента и сервера.
Дело в том, что пакеты, проходящие по сети, могут быть перехвачены, просмотрены и видоизменены. Используя пароли в сочетании с симметричными ключами шифрования, Kerberos производит аутентификацию пользователей и обеспечивает защиту передаваемых данных. Шифрование выполняется по алгоритмам DES и TripleDES.
MIT предоставил исходные коды протокола в открытый доступ всем желающим, однако на рынке можно приобрести и коммерческие версии (см. врезку «Ресурсы Internet»). Kerberos, в силу своего академического происхождения и использования UNIX в качестве платформы разработки, традиционно находил себе применение в первую очередь в колледжах и университетах, хотя немалым успехом он пользовался и в финансовых учреждениях. С включением Kerberos в состав операционной системы Microsoft Windows 2000 перед ним открывается возможность охватить гораздо более широкую аудиторию пользователей и разработчиков.
Как и следовало ожидать, обращение Microsoft к протоколу с открытым исходным кодом было встречено со смешанными чувствами. Такой шаг несомненно повысил престиж Kerberos, однако при этом Microsoft «перекроила» весь протокол, добавив в него свои собственные функции; это создало предпосылки для проблем взаимодействия в средах, где используется и UNIX, и Micro-soft Kerberos.
В настоящей статье рассматриваются основные принципы работы Ker-beros, описываются особенности реализации Microsoft и обсуждается будущее протокола.
ОСНОВЫ KERBEROS
У протокола Kerberos, как и у легендарного пса из преисподней, тоже три «головы»: два абонента безопасности и доверенная третья сторона. В роли абонентов выступают два устройства (обычно это клиент и сервер), которые желают установить связь друг с другом. У каждого из них имеется свой долгосрочный уникальный пароль (например, тот, который пользователь предъявляет при входе в систему). Доверенная третья сторона — центр распределения ключей (Key Distribution Center, KDC) — служит посредником, снабжая обоих абонентов безопасности секретным ключом, который будет использоваться ими сообща. KDC также знает пароли всех участников сеансов связи, которым он предлагает посреднические услуги. Эти пароли хранятся в зашифрованной базе данных.
Kerberos опирается на криптографию с секретными, или симметричными, ключами. В этом случае сообщение, отправляемое открытым текстом, может быть преобразовано в шифрованный (т. е. нечитаемый) текст, а затем вновь восстановлено в виде обычного текста — и все это производится с помощью одного ключа. Таким образом, обе участвующие стороны используют для шифрования и расшифровки направляемых друг другу сообщений общий секретный ключ.
Криптографию с секретными ключами следует отличать от криптографии на базе асимметричных ключей, которая предусматривает наличие у каждого участника двух ключей — открытого (общего) и скрытого (личного). Скрытый ключ — предмет строго индивидуального пользования.
Транзакция Kerberos состоит из манипулирования сеансовыми ключами и билетами. Сеансовый ключ — это секретный ключ, подготовленный специально для того, чтобы оба абонента безопасности могли совместно пользоваться одними и теми же идентификационными данными, и им была бы гарантирована целостность и конфиденциальность сообщений. Билет содержит важную информацию о транзакции и открывает запросившему его доступ к другому компьютеру. Клиент обязан получить сеансовый ключ и билет для каждого компьютера, к которому он хочет получить доступ.
В билете отмечается момент его создания и срок действия. Абоненты безопасности используют данные о времени создания билета в процессе аутентификации, поэтому их часы должны быть максимально точно синхронизированы друг с другом.
Срок действия билета отслеживается системой безопасности, для того чтобы ограничить масштабы возможного ущерба, который способен причинить злоумышленник, укравший каким-либо образом билет. Обычно билет действителен в течение рабочего дня, однако администратор может менять срок в сторону как уменьшения, так и увеличения, в зависимости от политики безопасности, осуществляемой в конкретной организации. При этом следует иметь в виду, что уменьшение срока действия может привести к увеличению объема трафика, так как абонентам безопасности придется чаще проходить аутентификацию (кстати, и конечные пользователи будут недовольны: им придется снова и снова вводить свои пароли).
Если размер сети достаточно велик, абонентов безопасности на зоны (realm). В каждую зону включаются все участники, имеющие прямое доверительное отношение с одним конкретным KDC. С помощью процедуры межзональной аутентификации представители разных зон могут связываться друг с другом.
ПРЕДЪЯВИТЕ БИЛЕТЫ!
В этом разделе подробно описывается простейшая транзакция Kerberos между двумя абонентами безопасности в среде Kerberos. Для наглядности предположим, что на одной клиентской станции работает пользователь по имени Алиса, и она хочет получить доступ к серверу по имени Боб.
В среде Kerberos процесс аутентификации начинается с входа в систему. Алиса вводит на клиентской станции свое имя пользователя и пароль. Рабочая станция посылает пользовательское имя Алисы в центр распределения ключей. Там содержится главная база данных уникальных, долгосрочных ключей всех участников сеансов связи данной зоны. KDC ищет главный ключ Алисы (KA), который он определяет на основании ее пароля. Потом KDC создает сеансовый ключ (SA), которым будет пользоваться совместно с Алисой, и «билет на выдачу билета» (Ticket-Granting Ticket, TGT). Билет TGT включает вторую копию сеансового ключа (SA), имя пользователя, введенное Алисой, и срок действия. KDC шифрует этот билет своим собственным главным ключом (KKDC), который известен только KDC.
Затем KDC шифрует всю эту информацию с помощью главного ключа Алисы (KA) и возвращает полученный результат на ее рабочую станцию. Получив сообщение, которое выглядит как беспорядочный набор случайных битов, клиентская станция применяет к паролю Алисы однонаправленную хэш-функцию, преобразующую пароль в главный ключ Алисы (KA). С его помощью станция расшифровывает полученный пакет и становится обладателем сеансового ключа (совместно с KDC) и билета TGT. Она может «забыть» главный ключ Алисы — для общения с KDC ей будет достаточно сеансового ключа (SA) и TGT.
Теперь предположим, что Алиса пытается получить доступ к Бобу (см. Рисунок). Вместо того чтобы установить с ним прямой контакт, станция Алисы обращается в KDC. При этом она передает билет TGT, запрос на доступ к Бобу и порцию данных под названием «аутентификатор» — специальную отметку времени. Аутентификатор шифруется с помощью сеансового ключа, который является общим для Алисы и KDC (SA).
KDC расшифровывает TGT, используя свой главный ключ (KKDC). Как вы помните, в билете TGT содержится пользовательское имя Алисы и копия общего сеансового ключа (SA). KDC применяет этот сеансовый ключ (SA) для расшифровки аутентификатора и поэтому может быть уверен, что данный запрос действительно поступил от Алисы, потому что только Алиса пользуется соответствующим общим сеансовым ключом (SA).
Далее KDC создает два билета — один для Алисы и один для Боба. Каждый билет содержит важную информацию, в том числе имя абонента безопасности, запросившего услугу, имя получателя запроса, время создания билета и срок его действия. Кроме того, в оба билета вносится новый ключ (KAB), который будет использоваться совместно Алисой и Бобом.
KDC шифрует билет Боба, используя его главный ключ (KB). Затем билет Боба вкладывается в билет Алисы, где наряду с прочими данными также содержится новый ключ (KAB): KDC шифрует весь этот массив общим с Алисой сеансовым ключом (SA), и посылает результат Алисе.
Что происходит дальше? Получив билет, Алиса расшифровывает его с помощью сеансового ключа (SA). Таким образом, у нее оказывается новый сеансовый ключ (KAB) и билет Боба (который она не может прочитать). Затем Алиса расшифровывает аутентификатор (отметку о времени) с помощью нового ключа (KAB) и отправляет Бобу аутентификатор вместе с его билетом. Получив все это, Боб сначала расшифровывает собственный билет, используя свой главный ключ (KB). Это открывает доступ к новому сеансовому ключу (KAB), который позволит расшифровать аутентификатор Алисы.
Теперь и у Алисы, и у Боба есть новый ключ (KAB). Боб может не сомневаться, что Алиса — именно та, за которую себя выдает, так как она зашифровала аутентификатор с помощью этого ключа (KAB). Если у Боба возникнет необходимость ответить Алисе, он воспользуется новым ключом (KAB). Алиса будет знать, что Боб — это именно Боб, и никто другой, потому что он мог получить новый ключ (KAB) только с помощью своего главного ключа (KAB).
Аналогичным образом Алиса может аутентифицировать себя при обращении к другим участникам. Для каждого запроса на установление связи KDC создаст уникальный сеансовый ключ, которым он пользуется совместно с инициатором запроса.
Если вам до сих пор удалось следить за ходом моей мысли, примите поздравления. Как бы то ни было, помните, что эта процедура аутентификации невидима для конечных пользователей и протекает за считанные секунды — гораздо быстрее, чем вы читали ее описание.
ХОТЕЛИ КАК ЛУЧШЕ...
Версия Kerberos 5 заменила протокол Microsoft NT LAN Manager (NTLM) в роли основного метода сетевой аутентификации для Windows 2000. (NTLM остается в составе системы для совместимости с предыдущими версиями.) Microsoft отмечает ряд преимуществ Kerberos по сравнению с NTLM, включая более высокую эффективность аутентификации при доступе к серверам, поддержку взаимной аутентификации, упрощенное управление доверительными отношениями и совместимость.
«На наш взгляд, это отличный отраслевой протокол, достойный поддержки и заслуживающий включения в общую платформу», — подчеркивает Джексон Шоу, менеджер по выпуску продуктов Windows 2000 Server.
Сторонники Kerberos, не причастные к Microsoft, выражают сдержанный оптимизм по поводу интеграции протокола. «По-моему, это очень важно для Kerberos», — считает доктор Клиффорд Нойман (он был главным разработчиком Kerberos в институте MIT, а сейчас руководит научно-исследовательскими работами в компании CyberSafe, выпускающей средства сетевой безопасности и, в частности, продающей коммерческую версию Kerberos). Нойман полагает, что доминирование Microsoft на рынке будет «дополнительным стимулом для производителей к интеграции механизма аутентификации Kerberos с их собственными приложениями и утилитами».
Пол Хилл из MIT, судя по всему, тоже доволен предложенной реализацией (с некоторыми оговорками): «Мне кажется, уже всем стало ясно, что, имея дело с Microsoft, надо соблюдать осмотрительность; люди очень настороженно относятся к любым расширениям, которые исходят от Micro-soft. Однако в целом я считаю, что их обращение к Kerberos — фактор положительный. Когда крупный производитель решает перейти на стандартный протокол, это в любом случае следует только приветствовать».
Хотя оказаться в сфере внимания Microsoft — большая честь для Kerbe-ros, приверженцы систем UNIX/Kerberos были разочарованы решением Microsoft дополнить этот открытый стандарт своими собственными доработками.
«Для Microsoft оказалось недостаточно просто включить Kerberos в общий контекст; им непременно нужно было «улучшить» протокол, добавив в него свои данные, и это было сделано с нарушением пусть не буквы, но духа спецификации», — утверждает Марк ван Хейнинген, архитектор систем безопасности для Internet в компании Aventail, выпускающей средства обеспечения безопасности, и рьяный сторонник Kerberos.
Споры ведутся вокруг необязательного поля данных в Kerberos версии 5, называемого полем данных авторизации. Microsoft помещает в него сертификат привилегированного доступа (Privilege Access Certificate, PAC). В результате Kerberos в системе Windows 2000 дополнительно наделяется возможностями авторизации: он сможет управлять полномочиями пользователей в соответствии с их принадлежностью к тем или иным группам Windows.
Сам факт использования этого поля разработчиками Microsoft не составляет проблемы. «Поле PAC в стандарте оставлено на усмотрение тех, кто занимается конкретной реализацией протокола, — они вправе задействовать его любым необходимым для них способом», — говорит Шоу. Однако при этом Microsoft, по словам д-ра Ноймана, накладывает «обременительные ограничения в отношении того, что можно делать» с ее версией этого поля.
Эти ограничения носят форму лицензионного соглашения, которое, по сути, гласит, что спецификацию можно читать, но любую функцию, связанную с данными авторизации, запрещается реализовать без разрешения Microsoft. (См. во врезке «Ресурсы Internet» ссылку на текст лицензионного соглашения.) Подобные ограничения несовместимы с концепцией стандарта с открытым исходным кодом. «У меня складывается ощущение, что многие в Microsoft так до сих пор и не уяснили для себя сущность открытых протоколов», — заявляет ван Хейнинген.
Так почему же корпорация все же решилась на такой шаг в отношении открытого стандарта? Все дело в контроллерах доменов, используемых на платформах Microsoft. Контроллер домена осуществляет централизованное управление учетными записями пользователей, компьютерами и группами. В Windows 2000 контроллер домена также выполняет функции сервера каталогов и центра распределения ключей Kerberos и контролирует применяемую в домене политику в отношении групп.
Шоу так объясняет рационализацию Microsoft: «Поле авторизации является специфическим для Win-dows 2000 и для способа взаимодействия контроллеров доменов Windows в сети. Использование этой информации позволило бы продукту другой компании имитировать контроллер домена. Поскольку добавление в сеть контроллера домена от стороннего разработчика может вызвать непредсказуемые результаты, мы хотим удостовериться в том, что компания, собирающаяся реализовать продукт такого типа, тесно сотрудничает с Microsoft».
Имитирование контроллера домена — это именно то, что хотел бы, но не может сделать Хилл. «Я разочарован, — признается он. — Схема Microsoft имеет побочный эффект, причем преднамеренного характера. Он заключается в том, что никакая другая реализация Kerberos не сможет предложить полную замену контроллера домена Windows 2000. Это означает, что MIT не в состоянии создать систему, пусть даже исключительно для своих нужд, где мы имели бы все преимущества контроллера доменa, но не использовали бы контроллер домена Microsoft. Я бы предпочел, чтобы у людей была возможность попытаться эмулировать работу контроллера домена и соперничать с Microsoft на их поле».
Кроме того, остается вопрос взаимодействия: сможет ли Kerberos из Windows 2000 работать совместно с реализацией Kerberos для UNIX?
Джексон Шоу (Microsoft) уверен, что сможет. «Если вы сегодня установите систему Kerberos для UNIX, она будет полностью совместима с Ker-beros для Microsoft, так что клиент, войдя в среду UNIX с помощью процедуры единой регистрации, получит доступ к Windows. И если этого не произойдет, то я очень хотел поговорить с этим пользователем: мы заинтересованы в том, чтобы здесь все проходило гладко».
Хилл подтверждает, что, несмотря на PAC, режим обычной аутентификации между Kerberos для UNIX и Kerberos для Windows 2000 по-прежнему действует. «Если прикладной сервис получит билет с этими данными авторизации и не будет знать, как с ними поступить, он просто проигнорирует их. Поэтому не нужно ничего ломать. Остальная часть билета по-прежнему останется в силе, как и любой другой билет».
Тем не менее Хилл отмечает, что существует вероятность того, что пользователи зоны Kerberos для UNIX окажутся отрезанными от служб Win-dows 2000. «Если сервер приложений Microsoft получит билет без данных авторизации, ему удастся аутентифицировать пользователя, но он не сможет автоматически решить, что пользователю разрешено: например, предоставлять ли ему доступ к определенному ресурсу».
На самом деле вы сможете пройти аутентификацию из зоны Kerberos в UNIX в зону Kerberos в Windows 2000, но, если в вашем билете не будет сертификата PAC, необходимого для Windows 2000, система не сможет узнать, какими службами вы уполномочены пользоваться, и откажет в доступе к службе.
Однако, продолжает Хилл, эти проблемы можно решить. «Если межзональная аутентификация настроена правильно и у вас есть KDC и зона на базе UNIX, работающие в тесном взаимодействии с KDC и зоной от Microsoft, то механизм становится прозрачным для пользователя, и все работает просто прекрасно». Хилл подчеркивает, что, по его мнению, добиться этого достаточно легко, хотя он и не поручится за всех остальных.
И Нойман, и Хилл отмечают факты плодотворного сотрудничества Mic-rosoft с их организациями (CyberSafe и MIT соответственно) в деле обеспечения взаимодействия. «Я думаю, конкретные люди, работающие с Kerberos в Microsoft, отнюдь не лишены здравого смысла, — говорит Нойман. — Они, по-видимому, искренне заинтересованы в том, чтобы Kerberos стал стандартом».
Того же мнения придерживается и Хилл: «Microsoft затратила массу времени и сил на то, чтобы приспособить систему для использования Kerberos. Не меньше времени и сил компания расходует на тестирование возможностей взаимодействия. Мне кажется, она довольно успешно справляется с этими задачами».
СТАРЫЙ ПЕС, НОВЫЕ ТРЮКИ
И MIT, и коммерческие разработчики планируют усовершенствовать Kerberos, добавив поддержку недавно принятого усовершенствованного стандарта шифрования (Advan-ced Encryption Standard, AES) — нового, более защищенного варианта протокола DES, отживающего свой век. По оценкам Ноймана, в редакции MIT поддержка AES может быть обеспечена уже к концу лета 2001 г.
Успешно продвигается интеграция Kerberos и PKI. В этой области Хилл обращает внимание на такие проекты, как PKINIT, PKCROSS и KX.509 (в университете шт. Мичиган).
Подводя итоги, можно сказать, что, хотя взятие на вооружение компанией Microsoft протокола Ker-beros и вызвало определенное недовольство в среде сторонников открытых кодов, тем не менее оно существенно повысило авторитет протокола и безусловно будет стимулировать разработку приложений, где используется аутентификация с помощью Kerberos.
Сторожевому псу с таким стажем работы, как у Kerberos, уже давно следовало бы отправиться на пенсию, однако протокол с годами ничуть не утратил своей надежности. Kerberos по-прежнему начеку — и этому, пожа-луй, не стоит удивляться: как-никак Цербер.
Эндрю Конри-Мюррей — редактор Network Magazine по вопросам бизнеса. С ним можно связаться по адресу amurray@cmp.com.
Ресурсы Internet
Пятая версия Kerberos подробно описывается в RFC 1510; текст см. по адресу: ftp://ftp.isi.edu/in-notes/rfc1510.txt/.
MIT предлагает массу материалов по Kerberos — ответы на наиболее распространенные вопросы, документацию, описания уязвимых мест системы безопасности. См. http://web.mit.edu/kerberos/www/.
У д-ра Клиффорда Ноймана, главного проектировщика системы аутентификации Kerberos, есть свой сайт Web, где можно найти множество полезных ссылок. См. http://www.bcneuman.com.
На Web-узле Джима Роума в статье «How to Kerberize Your Site» («Как защитить узел с помощью Kerberos») (http://www.y12.doe.gov/~jar/HowToKerb.html#Intro/) рассказывается, как установить систему аутентификации Kerberos. Здесь имеются ссылки на узлы коммерческих разработчиков Kerberos.
Microsoft предоставляет для общего доступа ряд информационных документов, касающихся Kerberos. См. http://www.microsoft.com/windows2000/ library/howitworks/security/kerberos.asp/ и http://www.microsoft.com/windows2000/ library/howitworks/security/kerbint.asp/.
Спецификация использования поля данных авторизации по версии Microsoft размещена на http://www.microsoft.com/technet/ security/kerberos/default.asp. Перейдя по ссылке внизу страницы, щелкните Kerberos PAC Specification («Спецификация PAC для Kerberos»). Для доступа к документу необходимо заключить лицензионное соглашение.