Kerberos () — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними. Kerberos выполняет аутентификацию в качестве службы аутентификации доверенной третьей стороны, используя криптографический ключ, при условии, что пакеты, проходящие по незащищённой сети, могут быть перехвачены, модифицированы и использованы злоумышленником. Kerberos построен на криптографии симметричных ключей и требует наличия центра распределения ключей. Расширения Kerberos могут обеспечить использование криптографии с открытым ключом на определённых этапах аутентификации.
История создания Первая версия протокола Kerberos была создана в 1983 году в Массачусетском технологическом институте (MIT) в рамках проекта . Основной целью проекта являлась разработка плана по внедрению компьютеров в учебный процесс MIT и сопутствующего этому ПО. Проект был образовательным, но в конечном итоге результат включил несколько программных продуктов, которые широко используются и сегодня (например, X Window System). Общедоступным этот протокол стал, начиная с версии 4.
Основные концепции Изложим основную концепцию протокола Kerberos. Предположим, что существует два человека, знающих один и тот же секрет, известный только этим двоим. Тогда любой из них сможет легко убедиться, что имеет дело со своим напарником. Для этого ему всего лишь придётся проверить, знает ли его собеседник общий секрет.
Пример.
Пункт 1. Договорённость о пароле. Пусть Алиса общается с Бобом. При этом Боб использует информацию только тогда, когда уверен, что информация получена от Алисы. Чтобы избежать подделки — они договорились между собой о пароле, который знают только они вдвоём. При получении сообщения Боб может заключить из письма — знает ли его собеседник пароль. Если собеседнику Боба пароль известен, то можно утверждать, что его собеседником является Алиса.
Пункт 2. Возникновение проблемы передачи пароля. Теперь определим — каким же образом Алисе и Бобу показывать знание пароля. Конечно, можно просто включить пароль в текст письма. Например: «Привет, Боб. Наш пароль.». Если бы только Боб и Алиса были уверены, что их письма никто не читает — тогда можно было бы воспользоваться этим способом. Но, к сожалению, почта передаётся по сети, в которой работают другие пользователи, среди которых есть любопытная Ева. Ева поставила себе задачу — выяснить пароль, известный только Бобу и Алисе, при помощи которого они обмениваются сообщениями друг с другом. Теперь совершенно ясно, что нельзя указывать пароль просто в тексте письма. Значит, о пароле нельзя говорить открыто, но при этом надо дать знать собеседнику, что пароль вам известен.
Пункт 3. Решение проблемы передачи пароля. Протокол Kerberos решает проблему передачи пароля средствами криптографии с секретным ключом. Вместо того, чтобы сообщать друг другу пароль, участники сеанса связи обмениваются криптографическим ключом, знание которого подтверждает личность собеседника. Но для того, чтобы такая технология была возможна, необходимо, чтобы общий ключ был симметричным, то есть, ключ должен обеспечивать и шифрование, и расшифровку сообщения.
Пункт 4. Проблема обмена паролями. При использовании простых протоколов, типа описанного выше, возникает одна важная проблема. В случае с Бобом и Алисой надо понять, как они договариваются о секретном ключе для переписки друг с другом. Конечно, люди могут встретиться и договориться, но ведь в сетевых переговорах участвуют и машины. Если под Алисой понимать клиентскую программу, а под Бобом — службу на сетевом сервере, то встретиться они никак не могут. Проблема состоит ещё в том, что, когда клиенту надо посылать сообщение на несколько серверов, в этом случае для каждого сервера ей придётся обзавестись отдельным ключом. А серверу тогда потребуется столько секретных ключей, сколько у него клиентов. Необходимость хранить на каждом компьютере такое количество ключей создаёт риск для всей системы безопасности.
Пункт 5. Решение проблемы обмена паролями. Для решения этих проблем проектом «Афина» и был разработан специальный протокол — Kerberos. По аналогии с древнегреческой мифологией, этот протокол был назван в честь трёхголового пса, который защищал выход из царства Аида, — Цербера, или более точно — Кербера. Трём головам Цербера в протоколе соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет центр распределения ключей «Key distribution center», KDC.
Центр распределения ключей KDC (или TGS — сервер выдачи мандатов или разрешений) Центр распределения ключей (KDС) — это служба, работающая на физически защищённом сервере. Центр хранит базу данных с информацией об учётных записях всех клиентов сети. Вместе с информацией о каждом абоненте в базе центра распределения ключей хранится криптографический ключ, известный только этому абоненту и службе центра. Этот ключ служит для связи клиента с центром.
Обращение клиента к серверу через KDC
Если клиент хочет обратиться к серверу — он посылает сообщение центру распределения ключей. Центр направляет каждому участнику сеанса копии сеансового ключа, действующие в течение небольшого промежутка времени. Назначение этих ключей — проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту — долговременного ключа данного клиента. Теоретически, для выполнения функций доверенного посредника центру распределения ключей достаточно направить сеансовые ключи непосредственно абонентам безопасности. Однако на практике реализовать такую схему чрезвычайно сложно. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным.
Сеансовые мандаты
В ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа, общего для данного клиента и KDC, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового мандата («session ticket»). Затем сеансовый мандат целиком шифруется с помощью долговременного ключа, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку мандата, несущего в себе шифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер. Получив ответ KDC, клиент извлекает из него мандат и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из мандата, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот мандат в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет «личность» клиента. Сервер, получив «удостоверение личности» клиента, прежде всего с помощью своего секретного ключа расшифровывает сеансовый мандат и извлекает из него сеансовый ключ, который затем использует для расшифрования аутентификатора клиента. Если все проходит нормально — делается заключение, что удостоверение клиента выдано доверенным посредником, то есть — службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает её клиенту в качестве собственного аутентификатора. Одно из достоинств применения сеансовых мандатов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений («credentials cache») клиента, который направляет мандат на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента мандат, расшифрует его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти. Такой метод даёт и ещё одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые мандаты можно использовать многократно. На случай же их хищения устанавливается срок годности мандата, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретной области. Обычно срок годности мандатов не превышает восьми часов, то есть — стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от неё, кэш-память удостоверений обнуляется, и все сеансовые мандаты вместе с сеансовыми ключами уничтожаются.
Развитие протокола
Ранние версии MIT разработал Kerberos для защиты сетевых услуг, предоставляемых проектом Athena. Протокол был назван в честь греческого мифологического персонажа Kerberos (или Cerberus), известного в греческой мифологии как чудовищный трёхголовый сторожевой пёс Аида. Существует несколько версий протокола. Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.
Стив Миллер () и Клиффорд Нойман (), главные конструкторы Kerberos версии 4 (которая использовала алгоритм шифрования DES с 56-битными ключами), опубликовали эту версию в 1989 году, хотя тогда они все ещё в первую очередь планировали её применение в проекте «Афина».
Kerberos 4 Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией, распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределённым системам (например, Andrew File System) использовали идеи Kerberos 4 для своих систем аутентификации.
Основы того, что должно было стать Kerberos 4, были описаны в техническом плане «Афина»Технический план проекта «Афина»., а окончательный вариант был закреплён в исходном коде эталонной реализации, опубликованной MIT.
Однако из-за ограничений на экспорт программного обеспечения, использующего шифрование, наложенных американским правительством, Kerberos 4 не мог быть распространён за пределами Соединённых Штатов. Так как Kerberos 4 при шифровании использовал алгоритм DES, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из неё весь код, касающийся шифрования. Данные меры позволили обойти ограничение на экспорт.
Позже Эррол Янг () в Университете связи Австралии (Bond University of Australia) добавил в эту версию собственную реализацию DES. Она называлась «E-Bones» (сокращение от «encrypted bones»История названия E-Bones) и могла свободно распространяться за пределами США.
В 2006 году было объявлено о прекращении поддержки Kerberos 4.
Kerberos 5 С целью преодоления проблем безопасности предыдущей версии Джоном Колем () и Клиффордом Ньюманом () была разработана 5 версия протокола, которая в 1993 году была опубликована в RFC 1510. По прошествии времени, в 2005 спецификацией начала заниматься IETF Kerberos work group. Опубликованные ими документы включают в себя:
характеристики шифрования и контрольной суммы (RFC 3961); стандарт шифрования Advanced Encryption Standard (AES) (RFC 3962); Kerberos 5 «The Kerberos Network Authentication Service (V5)» (RFC 4120), уточняет некоторые аспекты RFC 1510, и намерен использоваться для более подробного и чёткого описания; новое издание GSS-API спецификации «The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2.» (RFC 4121).