Kerberos (/ˈkɜːrbərɒs/) — сетевой протокол аутентификации, который предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними. Kerberos выполняет аутентификацию в качестве службы аутентификации доверенной третьей стороны, используя криптографический ключ, при условии, что пакеты, проходящие по незащищённой сети, могут быть перехвачены, модифицированы и использованы злоумышленником. Kerberos построен на криптографии симметричных ключей и требует наличия центра распределения ключей. Расширения Kerberos могут обеспечить использование криптографии с открытым ключом на определённых этапах аутентификации.

Первая версия протокола Kerberos была создана в 1983 году в Массачусетском технологическом институте (MIT) в рамках проекта «Афина»^[англ.]. Основной целью проекта являлась разработка плана по внедрению компьютеров в учебный процесс MIT и сопутствующего этому ПО. Проект был образовательным, но в конечном итоге результат включил несколько программных продуктов, которые широко используются и сегодня (например, X Window System). Общедоступным этот протокол стал, начиная с версии 4.

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

Пример.

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

Пункт 2. Возникновение проблемы передачи пароля. Теперь определим — каким же образом Алисе и Бобу показывать знание пароля. Конечно, можно просто включить пароль в текст письма. Например: «Привет, Боб. Наш пароль.». Если бы только Боб и Алиса были уверены, что их письма никто не читает — тогда можно было бы воспользоваться этим способом. Но, к сожалению, почта передаётся по сети, в которой работают другие пользователи, среди которых есть любопытная Ева. Ева поставила себе задачу — выяснить пароль, известный только Бобу и Алисе, при помощи которого они обмениваются сообщениями друг с другом. Теперь совершенно ясно, что нельзя указывать пароль просто в тексте письма. Значит, о пароле нельзя говорить открыто, но при этом надо дать знать собеседнику, что пароль вам известен.

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

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

Пункт 5. Решение проблемы обмена паролями. Для решения этих проблем проектом «Афина» и был разработан специальный протокол — Kerberos. По аналогии с древнегреческой мифологией, этот протокол был назван в честь трёхголового пса, который защищал выход из царства Аида, — Цербера, или более точно — Кербера. Трём головам Цербера в протоколе соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет центр распределения ключей «Key distribution center», KDC.

Центр распределения ключей (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 и использовались в целях тестирования. Эти реализации содержали существенные ограничения и были полезны только для изучения новых идей и выявления проблем, которые могли возникнуть во время разработки.

Стив Миллер (Steve Miller) и Клиффорд Нойман (Clifford Neuman), главные конструкторы Kerberos версии 4 (которая использовала алгоритм шифрования DES с 56-битными ключами), опубликовали эту версию в 1989 году, хотя тогда они все ещё в первую очередь планировали её применение в проекте «Афина».

Kerberos 4 впервые была опубликована 24 января 1989 года. Она стала первой версией, распространяемой за пределами MIT, подготовленной для нескольких производителей, которые включили её в свои операционные системы. Кроме того, другие крупные проекты по распределённым системам (например, Andrew File System) использовали идеи Kerberos 4 для своих систем аутентификации.

Основы того, что должно было стать Kerberos 4, были описаны в техническом плане «Афина»^[1], а окончательный вариант был закреплён в исходном коде эталонной реализации, опубликованной MIT.

Однако из-за ограничений на экспорт программного обеспечения, использующего шифрование, наложенных американским правительством, Kerberos 4 не мог быть распространён за пределами Соединённых Штатов. Так как Kerberos 4 при шифровании использовал алгоритм DES, организации за пределами США не могли по закону использовать данное программное обеспечение. В ответ на это команда разработчиков из MIT создала специальную версию Kerberos 4, исключив из неё весь код, касающийся шифрования. Данные меры позволили обойти ограничение на экспорт.

Позже Эррол Янг (Errol Young) в Университете связи Австралии (Bond University of Australia) добавил в эту версию собственную реализацию DES. Она называлась «E-Bones» (сокращение от «encrypted bones»^[2]) и могла свободно распространяться за пределами США.

В 2006 году было объявлено о прекращении поддержки Kerberos 4^[3].

С целью преодоления проблем безопасности предыдущей версии Джоном Колем (John Kohl) и Клиффордом Ньюманом (Clifford Neuman) была разработана 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).

В июне 2006 года был представлен RFC 4556 описывающий расширение для 5-й версии под названием PKINIT (англ. public key cryptography for initial authentication in Kerberos). Данный RFC описывал, как использовать асимметричное шифрование на этапе аутентификации клиента.

На следующий год (2007) MIT сформировали Kerberos Консорциум (Kerberos Consortium) по содействию дальнейшему развитию.

Распространение реализации Kerberos происходит в рамках авторского права, аналогичного правам для BSD.

В настоящее время множество ОС поддерживает данный протокол, в число которых входят:

• Windows 2000 и более поздние версии, которые используют Kerberos как метод аутентификации в домене между участниками. Некоторые дополнения к этому протоколу отражены в RFC 3244 «Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols». Документ RFC 4757 описывает использование RC4 Kerberos в Windows;
• различные UNIX и UNIX подобные ОС (Apple Mac OS X, Red Hat Enterprise Linux 4, FreeBSD, Solaris, AIX, OpenVMS). При этом существует две наиболее используемые реализации с открытым исходным кодом — MIT Kerberos и Heimdal, последняя из которых была изначально создана в Швеции из-за ограничений на экспорт криптографического ПО из США^[англ.].

Kerberos 4 в значительной степени основан на протоколе Нидхема-Шрёдера, но с двумя существенными изменениями.

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

Как результат, протокол Kerberos 4 содержит два логических компонента:

• Сервер аутентификации (сокр. СА, англ. Authentication Server, сокр. AS)
• Сервер выдачи мандатов или разрешений (англ. Ticket Granting Server, сокр. TGS).

Обычно эти компоненты поставляются как единая программа, которая запускается на центре распределения ключей (KDC — содержит базу данных логинов/паролей для пользователей и сервисов использующих Kerberos).

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

Первое сообщение, отправляемое центру распределения ключей — запрос к серверу аутентификации, так же известен как AS_REQ. Это сообщение отправляется открытым текстом и содержит идентификационные данные клиента, метку времени клиента и идентификатор сервера, предоставляющего мандат (TGS).

Когда центр распределения ключей получает сообщение AS_REQ, то он проверяет, что клиент, от которого пришёл запрос, существует, и его метка времени близка к локальному времени центра (обычно ± 5 минут). Данная проверка производится не для защиты от повторов (сообщение посылается открытым текстом), а для проверки соответствия времени. Если хотя бы одна из проверок не проходит — клиенту отправляется сообщение об ошибке, и он не аутентифицируется.

В случае удачной проверки сервер аутентификации генерирует случайный сеансовый ключ, который будет совместно использоваться клиентом и cервером выдачи мандатов или разрешений (данный ключ защищает дальнейшие запросы мандатов на другие сервисы). Центр распределения ключей создаёт 2 копии сессионного ключа: одну для клиента и одну для сервера выдачи мандатов.

Затем центр распределения ключей отвечает клиенту сообщением сервера аутентификации (AS_REP), зашифрованным долгосрочным ключом клиента. Это сообщение включает TGT, зашифрованный TGS ключом, копию сессионного ключа для клиента, время жизни мандата и идентификатор TGS (TGT содержит: копию сессионного ключа для TGS, идентификатор клиента, время жизни мандата, метку времени центра распределения ключей (KDC), IP-адрес клиента).

Когда пользователь захочет получить доступ к сервису — он подготовит сообщение для TGS_REQ, содержащее 3 части: идентификатор сервиса, копию TGT, полученную ранее, и аутентификатор (аутентификатор состоит из метки времени, зашифрованной сессионным ключом, полученным от сервера аутентификации, и служит для защиты от повторов).

При получении запроса мандата от клиента KDC формирует новый сессионный ключ для взаимодействия клиент/сервис. Затем отправляет ответное сообщение (TGS_REP), зашифрованное сессионным ключом, полученным от сервера аутентификации. Это сообщение содержит новый сеансовый ключ, мандат сервиса, зашифрованный долговременным ключом сервиса, идентификатор сервиса и время жизни мандата (содержит копию нового сессионного ключа, идентификатор клиента, время жизни мандата, локальное время центра распределения ключей, IP-адрес клиента).

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

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

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

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

Кроме того оригинальный протокол Kerberos 4 подвержен перебору по словарю. Данная уязвимость связана с тем, что KDC выдаёт по требованию зашифрованный TGT любому клиенту. Важность данной проблемы также подчёркивает то, что пользователи обычно выбирают простые пароли.

Чтобы усложнить проведение данной атаки, в Kerberos 5 было введено предварительное установление подлинности. На данном этапе KDC требует, чтобы пользователь удостоверил свою личность прежде, чем ему будет выдан мандат.

За предварительную аутентификацию отвечает политика KDC, если она требуется, то пользователь при первом запросе к серверу аутентификации получит сообщение KRB_ERROR. Это сообщение скажет клиенту, что необходимо отправлять AS_REQ запрос со своими данными для установления подлинности. Если KDC не опознаёт их, то пользователь получит другое сообщение KRB_ERROR, сообщающее об ошибке, и TGT не будет выдан.

Криптографические обозначения, используемые в протоколах проверки подлинности и обмена ключами

${\displaystyle A}$	Идентификаторы Алисы (Alice), инициатора сессии
${\displaystyle B}$	Идентификатор Боба (Bob), стороны, с которой устанавливается сессия
${\displaystyle T}$	Идентификатор Трента (Trent), доверенной промежуточной стороны
${\displaystyle K_{A},K_{B},K_{T}}$	Открытые ключи Алисы, Боба и Трента
${\displaystyle K_{A}^{-1},K_{B}^{-1},K_{T}^{-1}}$	Секретные ключи Алисы, Боба и Трента
${\displaystyle E_{A},\left\{...\right\}_{K_{A}}}$	Шифрование данных ключом Алисы, либо совместным ключом Алисы и Трента
${\displaystyle E_{B},\left\{...\right\}_{K_{B}}}$	Шифрование данных ключом Боба, либо совместным ключом Боба и Трента
${\displaystyle \left\{...\right\}_{K_{B}^{-1}},\left\{...\right\}_{K_{A}^{-1}}}$	Шифрование данных секретными ключами Алисы, Боба (цифровая подпись)
${\displaystyle I}$	Порядковый номер сессии (для предотвращения атаки с повтором)
${\displaystyle K}$	Случайный сеансовый ключ, который будет использоваться для симметричного шифрования данных
${\displaystyle E_{K},\left\{...\right\}_{K}}$	Шифрование данных временным сеансовым ключом
${\displaystyle T_{A},T_{B}}$	Метки времени, добавляемые в сообщения Алисой и Бобом соответственно
${\displaystyle R_{A},R_{B}}$	Случайные числа (nonce), которые были выбраны Алисой и Бобом соответственно

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

Алиса направляет доверенной стороне (Тренту) свой идентификатор и Боба:

${\displaystyle Alice\to \left\{A,B\right\}\to Trent}$

Трент генерирует два сообщения. Первое включает метку времени ${\displaystyle T_{T}}$, время жизни ключа ${\displaystyle L}$, новый сеансовый ключ для Алисы и Боба ${\displaystyle K}$ и идентификатор Боба ${\displaystyle B}$. Это сообщение шифруется общим ключом Алисы и Трента. Второе сообщение содержит то же самое, кроме идентификатора — он заменён на идентификатор Алисы ${\displaystyle A}$. Само сообщение шифруется общим ключом Трента и Боба:

${\displaystyle Trent\to \left\{E_{A}\left(T_{T},L,K,B\right),E_{B}\left(T_{T},L,K,A\right)\right\}\to Alice}$

Алиса генерирует сообщение из собственного идентификатора ${\displaystyle A}$ и метки времени ${\displaystyle T_{T}}$, после чего шифрует сообщение сеансовым ключом ${\displaystyle K}$ и посылает Бобу вместе со вторым сообщением от Трента:

${\displaystyle Alice\to \left\{E_{K}\left(A,T_{T}\right),E_{B}\left(T_{T},L,K,A\right)\right\}\to Bob}$

В целях собственной аутентификации Боб шифрует модифицированную метку времени ${\displaystyle T_{T}+1}$ общим сеансовым ключом ${\displaystyle K}$ и посылает её Алисе:

${\displaystyle Bob\to \left\{E_{K}\left(T_{T}+1\right)\right\}\to Alice}$

Важным предположением является синхронизированность часов всех участников протокола. Однако на практике используется синхронизация с точностью до нескольких минут с запоминанием истории передач (с целью обнаружения повтора) в течение некоторого времени.

Схема работы Kerberos 5 в настоящее время происходит следующим образом:

Вход пользователя в систему:

1. Пользователь вводит имя и пароль на клиентской машине.
2. Клиентская машина выполняет над паролем одностороннюю функцию (обычно хеш), и результат становится секретным ключом клиента/пользователя.

Аутентификация клиента:

1. Клиент отсылает запрос (AS_REQ) на СА для получения аутентификационных верительных данных и последующего их предоставления TGS серверу (впоследствии он будет их использовать для получения мандатов без дополнительных запросов на применение секретного ключа пользователя.) Данный запрос содержит:
   • Идентификатор клиента, его метка времени и идентификатор сервера.
2. Если политика KDC требует предварительной аутентификации, то пользователь получает сообщение KRB_ERROR, в ответ на которое посылает повторный запрос, но уже c данными для установления подлинности.
3. СА проверяет, есть ли такой клиент в базе. Если есть, то назад СА отправляет сообщение (AS_REP), включающее:
   • Сессионный ключ клиента или TGS, идентификатор TGS и время жизни мандата, зашифрованные секретным ключом клиента.
   • TGT (который включает идентификатор и сетевой адрес клиента, метку времени KDC, период действия мандата и сессионный ключ клиента или TGS), зашифрованный секретным ключом TGS.

Если же нет, то клиент получает новое сообщение, говорящее о произошедшей ошибке.

1. Получив сообщение, клиент расшифровывает свою часть для получения Сессионного Ключа клиента или TGS. Этот сессионный ключ используется для дальнейшего обмена с сервером TGS. (Важно: Клиент не может расшифровать TGT, так как оно зашифровано секретным ключом TGS) В этот момент у пользователя достаточно данных, чтобы авторизоваться на TGS.

Авторизация клиента на TGS:

1. Для запроса сервиса клиент формирует запрос на TGS (TGS_REQ) содержащий следующие данные:
   • TGT, полученный ранее и идентификатор сервиса.
   • Аутентификатор (составленный из ID клиента и временного штампа), зашифрованный на Сессионном Ключе Клиент/TGS.
2. После получения TGS_REQ, TGS извлекает из него TGT и расшифровывает его используя секретный ключ TGS. Это даёт ему сессионный ключ клиента или TGS. Им он расшифровывает аутентификатор. Затем он генерирует сессионный ключ клиент/сервис и посылает ответ (TGS_REP) включающий:
   • мандат сервиса (который содержит ID клиента, сетевой адрес клиента, метку времени KDC, время действия мандата и Сессионный Ключ клиент/сервис) зашифрованный секретным ключом сервиса.
   • Сессионный ключ клиент/сервис, идентификатор сервиса и время жизни мандата, зашифрованные на сессионном ключе Client/TGS.

Запрос сервиса клиентом:

1. После получения TGS_REP, у клиента достаточно информации для авторизации на сервисе. Клиент соединяется с ним и посылает сообщение содержащее:
   • Зашифрованный мандат сервиса полученный ранее.
   • Новый аутентификатор, зашифрованный на сессионном ключе клиент/сервис, и включающий ID клиента и метку времени.
2. Сервис расшифровывает мандат используя свой секретный ключ и получает сессионный ключ клиент/сервис. Используя новый ключ, он расшифровывает аутентификатор и посылает клиенту следующее сообщение для подтверждения готовности обслужить клиента и показать, что сервер действительно является тем, за кого себя выдаёт:
   • Метку времени, указанную клиентом + 1, зашифрованную на сессионном ключе клиент/сервис.
3. Клиент расшифровывает подтверждение, используя сессионный ключ клиент/сервис и проверяет, действительно ли метка времени корректно обновлена. Если это так, то клиент может доверять серверу и может начать посылать запросы на сервер.
4. Сервер предоставляет клиенту требуемый сервис.

Расширение PKINIT затронуло этап предварительной аутентификации клиента, после чего она стала происходить следующим образом:

1. Пользователь идентифицируется в системе и предъявляет свой закрытый ключ.
2. Клиентская машина формирует запрос на СА (AS_REQ), в котором указывает, что будет использоваться асимметричное шифрование. Отличие данного запроса заключается в том, что он подписывается (с помощью закрытого ключа клиента) и кроме стандартной информации содержит сертификат открытого ключа пользователя.
3. Получив запрос, KDC сначала проверяет достоверность сертификата пользователя, а затем электронную подпись (используя полученный открытый ключ пользователя). После этого KDC проверяет локальное время, присланное в запросе (для защиты от повторов).
4. Удостоверившись в подлинности клиента, KDC формирует ответ (AS_REP), в котором в отличие от стандартной версии, сеансовый ключ зашифровывается открытым ключом пользователя. Кроме того ответ содержит сертификат KDC и подписывается его закрытым ключом (аналогично запросу клиента).
5. Получив ответ, пользователь проверяет подпись KDC и расшифровывает свой сеансовый ключ (используя свой закрытый).

Дальнейшие этапы происходят согласно стандартному описанию Kerberos V5.

• Единая точка отказа: требуется постоянное наличие центрального сервера. Когда сервер Kerberos падает, новые пользователи не могут войти. Это может быть устранено с помощью нескольких серверов Kerberos и резервных механизмов аутентификации.
• Kerberos имеет строгие требования к времени, что означает, что часы участников должны быть синхронизированы в заданных пределах. Мандаты имеют время жизни и, если часы клиента не синхронизированы с часами сервера Kerberos, аутентификация не будет выполнена. Конфигурация по умолчанию требует, чтобы часы расходились не более чем на пять минут друг от друга. На практике, как правило, используются демоны Network Time Protocol для синхронизации часов у клиентов.
• Протокол администрирования не стандартизирован и зависит от конкретной реализации сервера. Смена пароля описана в RFC 3244.
• В случае использования симметричной криптографии (Kerberos может работать с использованием как симметричной, так и асимметричной (с открытым ключом) криптографии), так как все способы аутентификации управляются централизованно центром распределения ключей (KDC), эта особенность инфраструктуры аутентификации позволит злоумышленнику выдавать себя за пользователя.
• Каждый сетевой сервис, требующий смены имени хоста, должен будет обновить собственный набор ключей Kerberos. Это усложняет использование виртуального хостинга и кластеров.
• Kerberos требует, чтобы учётные записи пользователей, клиенты и пользователи услуг на сервере, все доверяли серверу Kerberos (все должны быть в одном и том же домене с Kerberos или в доменах, имеющих доверительные отношения друг с другом). Kerberos не может использоваться в случаях, когда пользователи хотят подключаться к службам от неизвестных / ненадёжных клиентов, как в обычном интернете.

Шифр DES может быть использован с Kerberos, однако он больше не является Интернет-стандартом, так как он является уязвимым. Уязвимости, однако, существуют во многих продуктах, использующих Kerberos, которые не были обновлены для замены DES на более новые шифры, такие как AES, например.

В ноябре 2014 года Microsoft выпустила патч (MS14-068), чтобы исправить уязвимость в реализации Windows сервера KDC. Уязвимость, согласно заявлению, позволяла пользователям «поднять» их привилегии до уровня домена.

• Технология единого входа
• Identity management
• SPNEGO
• S/Key
• SRP (Secure remote password protocol)
• GSS-API (Generic Security Services Application Program Interface)
• Host Identity Protocol (HIP)

• Шнайер Б. Глава 3. Основные протоколы. Протокол Kerberos // Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — С. 81. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
• Шнайер Б. Глава 24. Примеры практических реализаций. Протокол KERBEROS // Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — С. 627—633. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.
• Jason Garman. 1-3 // Kerberos:The Definitive Guide (неопр.). — 2003. — ISBN 0-596-00403-6.
• Шнайер Б. глава 24.5 Kerberos Брюс Шнайер // Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си = Applied Cryptography. Protocols, Algorithms and Source Code in C. — М.: Триумф, 2002. — 816 с. — 3000 экз. — ISBN 5-89392-055-4.

• http://www.ixbt.com/comm/kerberos5.shtml
• http://www.oszone.net/4188/Kerberos
• RFC 4120
• RFC 4556
• [1]
• [2]