15:23 Kerberos (протокол) | |
| Kerberos ( / к ɜːr б ər ɒ s / ) является компьютерной сетью аутентификации протокола , который работает на основе билетов , чтобы узлы связи по незащищенной сети , чтобы доказать свою идентичность друг с другом в безопасном режиме. Протокол был назван в честь персонажа Керберос (или Цербер ) из греческой мифологии , свирепого трехголового сторожевого пса Аида . Его разработчики нацелены в первую очередь на модель клиент-сервер, и она обеспечивает взаимную аутентификацию- и пользователь, и сервер проверяют личность друг друга. Сообщения протокола Kerberos защищены от перехватов и повторных атак . Kerberos основан на криптографии с симметричным ключом и требует доверенной третьей стороны , и при желании может использовать криптографию с открытым ключом на определенных этапах аутентификации. Kerberos по умолчанию использует UDP-порт 88. UNIX и Unix-подобные операционные системы Многие UNIX и UNIX-подобных операционных систем, в том числе FreeBSD , OpenBSD , Apple, MacOS , Red Hat Enterprise Linux , Oracle «s Solaris , IBM, AIX и Z / OS , HP, HP-UX и OpenVMS и другие, включают в себя программное обеспечение для проверки подлинности Kerberos пользователей или услуги. Встроенная реализация протокола аутентификации Kerberos V для клиентских агентов и сетевых служб, работающих на встроенных платформах, также доступна от компаний. Клиент аутентифицирует себя на сервере аутентификации (AS), который перенаправляет имя пользователя в центр распространения ключей (KDC) . KDC выдает билет для выдачи билетов (TGT) , который имеет метку времени и шифрует его с использованием секретного ключа службы выдачи билетов (TGS), и возвращает зашифрованный результат на рабочую станцию пользователя. Это делается нечасто, обычно при входе пользователя в систему; TGT истекает в какой-то момент, хотя он может быть прозрачно обновлен менеджером сеанса пользователя, когда они вошли в систему. Когда клиенту необходимо связаться со службой на другом узле («принципал», на языке Kerberos), клиент отправляет TGT в TGS, который обычно использует тот же хост, что и KDC. Служба должна быть зарегистрирована в TGS с именем участника службы (SPN) . Клиент использует SPN для запроса доступа к этой услуге. После проверки того, что TGT действителен и что пользователю разрешен доступ к запрошенной услуге, TGS выдает клиенту ключи билета и сеанса. Затем клиент отправляет билет на сервисный сервер (SS) вместе со своим сервисным запросом. Пользователь Клиентский логин Пользователь вводит имя пользователя и пароль на клиентских компьютерах . Другие учетные механизмы, такие как pkinit ( RFC 4556 ), позволяют использовать открытые ключи вместо пароля. Клиент преобразует пароль в ключ симметричного шифра. При этом используется либо встроенное планирование ключей, либо односторонний хэш , в зависимости от используемого набора шифров. Аутентификация клиента Клиент отправляет сообщение в виде открытого текста идентификатора пользователя в AS (сервер аутентификации), запрашивая услуги от имени пользователя. (Примечание: ни секретный ключ, ни пароль не отправляются в AS.) AS проверяет, находится ли клиент в его базе данных. Если это так, AS генерирует секретный ключ, хэшируя пароль пользователя, найденного в базе данных (например, Active Directory в Windows Server), и отправляет клиенту следующие два сообщения: Сообщение A: Ключ сеанса клиента / TGS, зашифрованный с использованием секретного ключа клиента / пользователя. Сообщение B: Ticket-Granting-Ticket (TGT, который включает в себя идентификатор клиента, сетевой адрес клиента , срок действия билета и сеансовый ключ клиента / TGS ), зашифрованные с использованием секретного ключа TGS. Как только клиент получает сообщения A и B, он пытается расшифровать сообщение A с помощью секретного ключа, сгенерированного из пароля, введенного пользователем. Если введенный пользователем пароль не совпадает с паролем в базе данных AS, секретный ключ клиента будет другим и, следовательно, не сможет расшифровать сообщение A. Используя действительный пароль и секретный ключ, клиент расшифровывает сообщение A для получения сеансового ключа клиента / TGS. , Этот сеансовый ключ используется для дальнейшей связи с TGS. (Примечание. Клиент не может расшифровать Сообщение B, поскольку оно зашифровано с использованием секретного ключа TGS.) На этом этапе у клиента достаточно информации для аутентификации в TGS. Авторизация обслуживания клиентов При запросе услуг клиент отправляет в TGS следующие сообщения: Сообщение C: составлено из TGT из сообщения B и идентификатора запрашиваемой услуги. Сообщение D: Аутентификатор (который состоит из идентификатора клиента и метки времени), зашифрованный с использованием ключа сеанса Client / TGS . После получения сообщений C и D TGS извлекает сообщение B из сообщения C. Он дешифрует сообщение B с использованием секретного ключа TGS. Это дает ему «ключ сеанса клиента / TGS». Используя этот ключ, TGS расшифровывает сообщение D (Authenticator) и сравнивает идентификатор клиента из сообщений C и D, если они совпадают, сервер отправляет клиенту следующие два сообщения: Сообщение E: Билет клиент-сервер (который включает в себя идентификатор клиента, сетевой адрес клиента, срок действия и ключ сеанса клиент / сервер ), зашифрованные с использованием секретного ключа службы. Сообщение F: ключ сеанса клиента / сервера, зашифрованный ключом сеанса клиента / TGS . Запрос на обслуживание клиента Получив сообщения E и F от TGS, клиент имеет достаточно информации для аутентификации на Сервисном сервере (SS). Клиент подключается к SS и отправляет следующие два сообщения: Сообщение E: из предыдущего шага ( тикет клиент-сервер , зашифрованный с использованием секретного ключа сервиса). Сообщение G: новый Аутентификатор, который включает идентификатор клиента, метку времени и зашифрован с использованием ключа сеанса клиент / сервер . SS расшифровывает билет (сообщение E), используя свой собственный секретный ключ, чтобы получить ключ сеанса клиент / сервер . Используя ключ сессий, SS расшифровывает Authenticator и сравнивает идентификатор клиента из сообщений E и G, если они совпадают, сервер отправляет клиенту следующее сообщение, чтобы подтвердить его подлинную личность и готовность обслуживать клиента: Сообщение H: отметка времени, найденная в Authenticator клиента (плюс 1 в версии 4, но не обязательно в версии ), зашифрованная с использованием ключа сеанса клиент / сервер . Клиент расшифровывает подтверждение (сообщение H) с помощью ключа сеанса клиент / сервер и проверяет правильность метки времени. Если это так, то клиент может доверять серверу и может начать отправлять запросы на обслуживание серверу. Сервер предоставляет запрошенные услуги клиенту. | |
|
| |
| Всього коментарів: 0 | |