06-10-2023
Kerberos /kɛərbərəs/ — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Он ориентирован в первую очередь на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга. Данная модель является одним из вариантов Нидхем-Шрёдер-протокола аутентификации на основе доверенной третьей стороны и его модификациях, предложенных Denning и Sacco[1]
Содержание |
В 1983 году при поддержке консорциума производителей компьютеров был создан проект «Афина». Его основной целью являлась разработка плана по внедрению компьютеров в учебный процесс MIT и сопутствующего этому ПО. Хотя проект был образовательным, конечный результат включал несколько программных продуктов, которые широко используются и сегодня (например, X Window System).
Стандартные протоколы удаленного входа того времени отправляли свои верительные данные по сети в открытом виде. Кроме того, ПО сервера, такое как Rlogin вслепую доверяло идентификационным данным. Таким образом, недобросовестные пользователи могли без проблем получить доступ к чужой информации. Очевидно, что возможность потери своего пароля или кражи научной работы была недопустима для академической среды.
Для решения этих проблем проектом Афина и был разработан специальный протокол — Kerberos. По аналогии с древнегреческой мифологией, этот протокол был назван в честь трёхголового пса, который защищал вход в царство Аида, — Цербера, или более точно Кербера.
Ранние версии Kerberos (c 1 по 3) были созданы внутри МIT и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.
Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределенным системам (например AFS) использовали идеи Kerberos 4 для своих систем аутентификации. Основными разработчиками данной версии были Стив Миллер (Steve Miller) и Клиффорд Ньюман (Clifford Neuman).
Основы того, что должно было стать Kerberos 4 были описаны в техническом плане Афина[2], а окончательный вариант был закреплен в исходном коде эталонной реализации опубликованной MIT.
Однако, из-за ограничений на экспорт программного обеспечения использующего шифрование, наложенное американским правительством, Kerberos 4 не мог быть распространен за пределами Соединенных Штатов. Так как Kerberos 4 использовал DES шифрование, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это, команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из нее весь код касающийся шифрования. Данные меры позволили обойти ограничение на экспорт.
Позже, Эррол Янг(Errol Young) в университете Связи Австралии(Bond University of Australia), добавил в эту версию собственную реализацию DES. Она называлась"E-Bones" (сокращение от Encrypted Bones[3]) и могла свободно распространятся за пределами США.
В 2006 году было объявлено о прекращении поддержки Kerberos 4[4].
С целью преодоления проблем безопасности предыдущей версии Джоном Коулом (John Kohl) и Клиффардом Ньюманом (Clifford Neuman) была разработана 5 версия протокола, которая в 1993 году была опубликована в RFC 1510. По прошествии времени, в 2005 спецификацией начала заниматься IETF Kerberos work group. Опубликованные ими документы включают в себя:
В июне 2006 года был представлен RFC 4556 описывающий расширение для пятой версии под названием PKINIT (Public Key Cryptography for Initial Authentication in Kerberos). Данный RFC описывал, как использовать асимметричное шифрование на этапе аутентификации клиента.
На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.
Распространение реализации Kerberos происходит в рамках авторского права аналогичного правам для BSD.
В настоящее время множество ОС поддерживают данный протокол, в число которых входят:
Kerberos 4 в значительной степени основан на протоколе Нидхема-Шредера, но с двумя существенными изменениями:
Как результат, протокол Kerberos 4 содержит два логических компонента: Сервер аутентификации (СА) и сервер выдачи билетов (TGS — Ticket Granting Server). Обычно эти компоненты поставляются как единая программа, которая запускается на центре распределения ключей (ЦРК — содержит базу данных логинов/паролей для пользователей и сервисов использующих Kerberos).
Сервер аутентификации выполняет одну функцию: получает запрос содержащий имя клиента запрашивающего аутентификацию и возвращает ему зашифрованный TGT. Затем пользователь может использовать этот TGT, для запроса дальнейших билетов на другие сервисы. В большинстве реализаций Kerberos время жизни TGT 8-10 часов. После этого клиент снова должен запросить его у СА.
Первое сообщение, отправляемое центру распределения ключей — запрос к СА, так же известен как AS_REQ. Это сообщение отправляется открытым текстом и содержит идентификационные данные клиента, метку времени клиента и идентификатор сервера предоставляющего билет (TGS).
Когда ЦРК получает AS_REQ сообщение, он проверяет, что клиент, от которого пришел запрос, существует, и его метка времени близка к локальному времени ЦРК (обычно ± 5 минут). Данная проверка производится не для защиты от повторов (сообщение посылается открытым текстом), а для проверки соответствия времени. Если хотя бы одна из проверок не проходит, то клиенту отправляется сообщение об ошибке, и он не аутентифицируется.
В случае удачной проверки СА генерирует случайный сеансовый ключ, который будет совместно использоваться клиентом и TGS (данный ключ защищает дальнейшие запросы билетов у TGS на другие сервисы). ЦРК создает 2 копии сессионного ключа: одну для клиента и одну для TGS.
Затем ЦРК отвечает клиенту сообщением сервера аутентификации (AS_REP) зашифрованным долгосрочным ключом клиента. Которое включает TGT зашифрованный TGS ключом (TGT содержит: копию сессионного ключа для TGS, идентификатор клиента, время жизни билета, метку времени ЦРК, IP адрес клиента), копию сессионного ключа для клиента, время жизни билета и идентификатор TGS.
Когда пользователь захочет получить доступ к сервису, он подготовит сообщение для TGS (TGS_REQ) содержащее 3 части: идентификатор сервиса, копию TGT полученную ранее и аутентификатор (Аутентификатор состоит из метки времени зашифрованной сессионным ключом полученным от СА и служит для защиты от повторов).
При получении запроса билета от клиента, ЦРК формирует новый сессионный ключ для взаимодействия клиент/сервис. Затем отправляет ответное сообщение (TGS_REP) зашифрованное сессионным ключом полученным от СА. Это сообщение содержит новый сеансовый ключ, билет сервиса (Service ticket содержит: копию нового сессионного ключа, идентификатор клиента, время жизни билета, локальное время ЦРК, IP клиента) зашифрованный долговременным ключом сервиса, идентификатор сервиса и время жизни билета.
Детали последнего шага — отправки билета службы серверу приложений не стандартизировались Kerberos 4, поэтому его реализация полностью зависит от приложения.
Kerberos 5 является развитием четвертой версии, включает всю предыдущую функциональность и содержит множество расширений. Однако, с точки зрения реализации, Kerberos 5 является абсолютно новым протоколом.
Основной причинной появления пятой версии являлась невозможность расширения. Со временем, атака полным перебором на DES используемом в Kerberos 4 стала актуальна, но используемые поля в сообщениях имели фиксированный размер и использовать более стойкий алгоритм шифрования не представлялось возможным.
Для решения данной проблемы было решено создать расширяемый протокол с возможностью использования на различных платформах на основе технологии ASN.1. Это позволило использовать в транзакциях различные типы шифрования. Благодаря этому была реализована совместимость с предыдущей версией. Кроме того у ЦРК появляется возможность выбирать наиболее безопасный протокол шифрования поддерживаемый участвующими сторонами.
Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем, что ЦРК выдает по требованию зашифрованный TGT любому клиенту. Важность данной проблемы так же подчеркивает то, что пользователи обычно выбирают простые пароли.
Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление подлинности. На данном этапе ЦРК требует, чтобы пользователь удостоверил свою личность прежде, ему будет выдан билет.
За предварительную аутентификацию отвечает политика ЦРК, если она требуется, то пользователь при первом запросе к СА получит сообщение KRB_ERROR. Это сообщение скажет клиенту, что необходимо отправлять AS_REQ запрос со своими данными для установления подлинности. Если ЦРК не опознает их, то пользователь получит другое сообщение KRB_ERROR, сообщающее об ошибке и TGT не будет выдан.
Идентифкаторы Алисы (Alice), инициатора сессии | |
Идентифкатор Боба (Bob), стороны, с которой устанавливается сессия | |
Идентифкатор Трента (Trent), доверенной промежуточной стороны | |
Шифрование данных ключом Алисы, либо совместным ключом Алисы и Трента | |
Шифрование данных ключом Боба, либо совместным ключом Боба и Трента | |
Порядковый номер сессии (для предотвращения атаки с повтором) | |
Случайный сеансовый ключ, который будет использоваться для симетричного шифрования данных | |
Шифрование данных временным сеансовым ключом | |
Метки времени, добавляемые в сообщения Алисой и Бобом соответственно | |
Случайные числа (nonce), которые были выбраны Алисой и Бобом соответственно |
Протокол использует только симметричное шифрование и предполагает, что у каждого корреспондента (Алисы и Боба) есть общий секретный ключ с третьей доверенной стороной (Трентом).
Алиса направляет доверенной стороне (Тренту) свой идентификатор и Боба:
Трент генерирует два сообщения. Первое включает метку времени , время жизни ключа , новый сеансовый ключ для Алисы и Боба и идентификатор Боба . Это сообщение шифруется общим ключом Алисы и Трента. Второе сообщение содержит то же самое, кроме идентификатора — он заменён на идентификатор Алисы . Само сообщение шифруется общим ключом Трента и Боба:
Алиса генерирует сообщение из собственного идентификатора и метки времени , после чего шифрует сообщение сеансовым ключом и посылает Бобу вместе со вторым сообщением от Трента:
В целях собственной аутентификации Боб шифрует модифицированную метку времени общим сеансовым ключом и посылает её Алисе:
Важным предположением является синхронизированность часов всех участников протокола. Однако на практике используется синхронизация с точностью до нескольких минут с запоминанием истории передач (с целью обнаружения повтора) в течение некоторого времени.
Схема работы Kerberos 5 в настоящее время происходит следующим образом:
Вход пользователя в систему:
Аутентификация клиента:
Авторизация клиента на TGS:
Запрос сервиса клиентом:
Расширение PKINIT затронуло этап предварительной аутентификации клиента. После чего она стала происходить следующим образом:
Дальнейшие этапы происходят согласно стандартному описанию Kerberos V5.
Протоколы аутентификации и обмена ключами | |
---|---|
С симметричными алгоритмами | |
С симметричными и асимметричными алгоритмами | |
Протоколы и сервисы, используемые в Internet |
Kerberos.