|
|
| Протокол Kerberos |
|
. Боб шифрует время из сообщения Алисы с помощью их общего ключа и включает его в собственное сообщение, которое направляет Алисе.Обратите внимание, что Боб возвращает Алисе не всю информацию из ее аутентификатора, а только время. Если бы он отправил все сразу, у Алисы закралось бы подозрение, что кто-то, решив притвориться Бобом, просто скопировал аутентификатор из ее исходного сообщения и без каких-либо изменений отправил его назад. Но в полученном письме содержится только часть информации, а это значит, что получатель исходного аутентификатора смог расшифровать его и обработать содержащуюся там информацию. А время он выбрал потому, что это поле является уникальным идентификатором сообщения Алисы. Алиса получает ответ Боба, расшифровывает его, а затем сравнивает полученный результат со временем, которое было указано в исходном аутентификаторе. Если эти данные совпадают, она может быть уверена, что ее аутентификатор дошел до того, кто знает их с Бобом секретный ключ. Этот человек смог расшифровать сообщение и извлечь из него информацию о времени. Поскольку ни она, ни Боб никому свой ключ не передавали, Алиса делает вывод, что именно Боб получил ее аутентификатор и ответил на него. Взаимная аутентификация представлена на рисунке 1.Рисунок 1 - Взаимная аутентификация (Алиса-Боб) Управление ключамиПри использовании простых протоколов, наподобие описанного выше, возникает одна очень важная проблема. В случае с Алисой и Бобом мы ни слова не сказали о том, как и где они договаривались о секретном ключе для своей переписки. Конечно, люди могут просто встретиться в парке и обсудить все детали, но ведь в сетевых переговорах участвуют машины. Если под Алисой понимать клиентскую программу, установленную на рабочей станции, а под Бобом - службу на сетевом сервере, то встретиться они никак не могут. Проблема еще более осложняется в тех случаях, когда Алисе - клиенту - нужно посылать сообщения на несколько серверов, ведь для каждого из них придется обзавестись отдельным ключом. Да и службе по имени Боб потребуется столько секретных ключей, сколько у нее клиентов. Но если каждому клиенту для поддержания связи с каждой службой требуется индивидуальный ключ, и такой же ключ нужен каждой службе для каждого клиента, то проблема обмена ключами очень быстро приобретает предельную остроту. Необходимость хранения и защиты такого множества ключей на огромном количестве компьютеров создает невероятный риск для всей системы безопасности.Само название протокола Kerberos говорит о том, как здесь решена проблема управления ключами. Кербер (или Цербер) - персонаж классической греческой мифологии. Этот свирепый пес о трех головах, по поверьям греков, охраняет врата подземного царства мертвых. Трем головам Кербера в протоколе Kerberos соответствуют три участника безопасной связи: клиент, сервер и доверенный посредник между ними. Роль посредника здесь играет так называемый центр распределения ключей Key Distribution Center или, сокращенно, KDCKDC представляет собой службу, работающую на физически защищенном сервере. Она ведет базу данных с информацией об учетных записях всех главных абонентов безопасности (security principal) своей области (области Kerberos в сетях Windows 2000 соответствует домен, поэтому в дальнейшем мы будем применять именно этот привычный термин). Вместе с информацией о каждом абоненте безопасности в базе данных KDC сохраняется криптографический ключ, известный только этому абоненту и службе KDC. Данный ключ, который называют долговременным, используется для связи пользователя системы безопасности с центром распределения ключей. В большинстве практических реализаций протокола Kerberos долговременные ключи создаются на основе пароля пользователя.Когда клиенту нужно обратиться к серверу, он, прежде всего, направляет запрос в центр KDC, который в ответ направляет каждому участнику предстоящего сеанса копии уникального сеансового ключа (session key), действующие в течение короткого времени. Назначение этих ключей - проведение аутентификации клиента и сервера. Копия сеансового ключа, пересылаемая на сервер, шифруется с помощью долговременного ключа этого сервера, а направляемая клиенту - долговременного ключа данного клиента.Рисунок.2. Управление ключами (в теории)Теоретически, для выполнения функций доверенного посредника центру KDC достаточно направить сеансовые ключи непосредственно абонентам безопасности, как показано выше. Однако на практике реализовать такую схему чрезвычайно сложно. Прежде всего, серверу пришлось бы сохранять свою копию сеансового ключа в памяти до тех пор, пока клиент не свяжется с ним. А ведь сервер обслуживает не одного клиента, поэтому ему нужно хранить пароли всех клиентов, которые могут потребовать его внимания. В таких условиях управление ключами требует значительной затраты серверных ресурсов, что ограничивает масштабируемость системы. Нельзя забывать и о превратностях сетевого трафика. Они могут привести к тому, что запрос от клиента, уже получившего сеансовый пароль, поступит на сервер раньше, чем сообщение KDC с этим паролем. В результате серверу придется повременить с ответом до тех пор, пока он не получит свою копию сеансового пароля. То есть, нужно будет сохранить состояния сервера, а это накладывает на его ресурсы еще одно тяжкое бремя. Поэтому на практике применяется другая схема управления паролями, которая делает протокол Kerberos гораздо более эффективным. Ее описание приводится ниже.Сеансовые билетыВ ответ на запрос клиента, который намерен подключиться к серверу, служба KDC направляет обе копии сеансового ключа клиенту, как показано на рис.3. Сообщение, предназначенное клиенту, шифруется посредством долговременного ключа клиента, а сеансовый ключ для сервера вместе с информацией о клиенте вкладывается в блок данных, получивший название сеансового билета (session ticket). Затем сеансовый билет целиком шифруется с помощью долговременного ключа сервера, который знают только служба KDC и данный сервер. После этого вся ответственность за обработку билета, несущего в себе зашифрованный сеансовый ключ, возлагается на клиента, который должен доставить его на сервер. Рисунок.3. Управление ключами (на практике)Обратите внимание, что в данном случае функции службы KDC ограничиваются выдачей билета. Ей больше не нужно следить за тем, все ли отправленные сообщения доставлены соответствующим адресатам. Даже если какое-нибудь из них попадет не туда, - ничего страшного не случится. Расшифровать клиентскую копию сеансового ключа может только тот, кто знает секретный долговременный ключ данного клиента, а чтобы прочесть содержимое сеансового билета, нужен долговременный секретный ключ сервера. Получив ответ KDC, клиент извлекает из него сеансовый билет и свою копию сеансового ключа, которые помещает в безопасное хранилище (оно располагается не на диске, а в оперативной памяти). Когда возникает необходимость связаться с сервером, клиент посылает ему сообщение, состоящее из билета, который по-прежнему зашифрован с применением долговременного ключа этого сервера, и собственного аутентификатора, зашифрованного посредством сеансового ключа. Этот билет в комбинации с аутентификатором как раз и составляет удостоверение, по которому сервер определяет "личность" клиента.Рисунок.4. Взаимная аутентификация (клиент-сервер)Сервер, получив "удостоверение личности" клиента, с помощью своего секретного ключа расшифровывает сеансовый билет и извлекает из него сеансовый ключ, который затем использует для расшифрования аутентификатора клиента. Если все проходит нормально, делается заключение, что удостоверение клиента выдано доверенным посредником, то есть, службой KDC. Клиент может потребовать у сервера проведения взаимной аутентификации. В этом случае сервер с помощью своей копии сеансового ключа шифрует метку времени из аутентификатора клиента и в таком виде пересылает ее клиенту в качестве собственного аутентификатора.Одно из достоинств применения сеансовых билетов состоит в том, что серверу не нужно хранить сеансовые ключи для связи с клиентами. Они сохраняются в кэш-памяти удостоверений (credentials cache) клиента, который направляет билет на сервер каждый раз, когда хочет связаться с ним. Сервер, со своей стороны, получив от клиента билет, расшифровывает его и извлекает сеансовый ключ. Когда надобность в этом ключе исчезает, сервер может просто стереть его из своей памяти.Такой метод дает и еще одно преимущество: у клиента исчезает необходимость обращаться к центру KDC перед каждым сеансом связи с конкретным сервером. Сеансовые билеты можно использовать многократно. На случай же их хищения устанавливается срок годности билета, который KDC указывает в самой структуре данных. Это время определяется политикой Kerberos для конкретного домена. Обычно срок годности билетов не превышает восьми часов, то есть, стандартной продолжительности одного сеанса работы в сети. Когда пользователь отключается от нее, кэш-память удостоверений обнуляется, и все сеансовые билеты вместе с сеансовыми ключами уничтожаются. Билеты на выдачу билетовКак уже отмечалось, долговременный ключ пользователя создается на основе его пароля. Чтобы лучше понять это, вернемся к нашему примеру. Когда Алиса проходит регистрацию, клиент Kerberos, установленный на ее рабочей станции, пропускает указанный пользователем пароль через функцию хеширования (все реализации протокола Kerberos 5 должны обязательно поддерживать алгоритм DES-CBC-MD5, хотя могут применяться и другие алгоритмы). В результате формируется криптографический ключ.В центре KDC долговременные ключи Алисы хранятся в базе данных с учетными записями пользователей. Получив запрос от клиента Kerberos, установленного на рабочей станции Алисы, KDC обращается в свою базу данных, находит в ней учетную запись нужного пользователя и извлекает из соответствующего ее поля долговременный ключ Алисы.Такой процесс - вычисление одной копии ключа по паролю и извлечение другой его копии из базы данных - выполняется всего лишь один раз за сеанс, когда пользователь входит в сеть впервые. Сразу же после получения пользовательского пароля и вычисления долговременного ключа клиент Kerberos рабочей станции запрашивает сеансовый билет и сеансовый ключ, которые используются во всех последующих транзакциях с KDC на протяжении текущего сеанса работы в сети.На запрос пользователя KDCотвечает специальным сеансовым билетом для самого себя, так называемый билет на выдачу билетов (ticket-granting ticket), или билет TGT. Как и обычный сеансовый билет, TGT содержит копию сеансового ключа для связи службы (в данном случае - KDC) с клиентом. В сообщение с билетом TGT также включается копия сеансового ключа, с помощью которой клиент может связаться с KDC. Билет TGT шифруется посредством долговременного ключа службы KDC, а клиентская копия сеансового ключа - с помощью долговременного ключа пользователя.Получив ответ службы KDC на свой первоначальный запрос, клиент расшифровывает свою копию сеансового ключа, используя для этого копию долговременного ключа пользователя из своей кэш-памяти. После этого долговременный ключ, полученный из пользовательского пароля, можно удалить из памяти, поскольку он больше не понадобится: вся последующая связь с KDC будет шифроваться с помощью сеансового ключа. Как и все другие сеансовые ключи, он имеет временный характер и действителен до истечения срока действия билета TGT, либо до выхода пользователя из системы. По этой причине такой ключ называют сеансовым ключом регистрации (logon session key). С точки зрения клиента, билет TGT почти ничем не отличается от обычного. Перед подключением к любой службе, клиент, прежде всего, обращается в кэш-память удостоверений и достает оттуда сеансовый билет для этой службы. Если его нет, он начинает искать в этой же кэш-памяти билет TGT. Найдя его, клиент извлекает оттуда же соответствующий сеансовый ключ регистрации и готовит с его помощью аутентификатор, который вместе с TGT высылает в KDC. Одновременно туда направляется запрос на сеансовый билет для требуемой службы. Другими словами, организация безопасного доступа к KDC ничем не отличается от организации такого доступа к любой другой службе домена - она требует сеансового ключа, аутентификатора и билета (в данном случае TGT). С точки же зрения службы KDC, билеты TGT позволяют ускорить обработку запросов на получение билетов, сэкономив несколько наносекунд на пересылке каждого из них. Центр распределения ключей KDC обращается к долговременному ключу пользователя только один раз, когда предоставляет клиенту первоначальный билет TGT. Во всех последующих транзакциях с этим клиентом центр KDC расшифровывает билеты TGT с помощью собственного долговременного ключа и извлекает из него сеансовый ключ регистрации, который использует для проверки подлинности аутентификатора клиента. Аутентификация за пределами доменаФункции центра KDC можно разделить на две категории: службу аутентификации, в задачу которой входит генерация билетов TGT, и службу выдачи билетов, создающую сеансовые билеты. Такое разделение труда позволяет применять протокол Kerberos и за пределами его "родного" домена. Клиент, получивший билет TGT из службы аутентификации одного домена, может воспользоваться им для получения сеансовых билетов в службах выдачи билетов других доменов.Чтобы лучше понять принцип междоменной аутентификации, рассмотрим для начала простейшую сеть, содержащую всего два домена - "Восток" и "Запад". Предположим, что администраторы этих доменов являются сотрудниками одной организации или у них есть какие-либо другие веские причины уравнять пользователей второго домена со своими собственными. В любом из этих случаев наладить аутентификацию между доменами нетрудно, для этого достаточно договориться о едином междоменном ключе (в Windows 2000 такой ключ генерируется автоматически, когда между доменами устанавливаются доверительные отношения). Как только ключ создан, служба выдачи билетов каждого домена регистрируется в центре KDC другого домена в качестве главного абонента безопасности. В результате служба выдачи билетов каждого из доменов начинает рассматривать службу выдачи билетов второго домена, как еще одну свою службу. Благодаря этому клиент, прошедший аутентификацию и зарегистрировавшийся в системе, может запрашивать и получать сеансовые билеты для нее.
Страницы: 1, 2, 3
|
|
|
|
© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент. |
|
|
