Криптографические протоколы

Размещено на http://www.allbest.ru

Практическая работа № 1. Протоколы аутентификации

Типы аутентификации

Как известно, практически в любых компьютерных системах существует необходимость аутентификации. В ходе этой процедуры компьютерная система проверяет, действительно ли пользователь тот, за кого себя выдает. Для того, чтобы получить доступ к компьютеру, в Интернет, к системе удаленного управления банковским счетом и т. д., пользователю необходимо убедительно доказать компьютерной системе, что "он есть та самая персона", а не кто-либо еще. Для этого он должен предъявить системе некую аутентификационную информацию, на основании которой модуль аутентификации данной системы выносит решение о предоставлении ему доступа к требуемому ресурсу (доступ разрешен/нет).

В настоящее время для такой проверки применяется информация трех видов. аутентификация криптографический протокол безопасность

Первый - уникальная последовательность символов, которую пользователь должен знать для успешного прохождения аутентификации. Простейший пример - парольная аутентификация, для которой достаточно ввести в систему свой идентификатор (например, логин) и пароль.

Второй вид информации - уникальное содержимое или уникальные характеристики предмета. Простейший пример - ключ от любого замка. В случае же компьютерной аутентификации в этом качестве выступают любые внешние носители информации: смарт-карты, электронные таблетки iButton, USB-токены и т. д.

И, наконец, третий вид аутентификации - по биометрической информации, которая неотъемлема от пользователя. Это может быть отпечаток пальца, рисунок радужной оболочки глаза, форма лица, параметры голоса и т.д.

Очень часто комбинируют несколько видов информации, по которой проводится аутентификация. Типичный пример: аутентификационная информация хранится на смарт-карте, для доступа к которой нужно ввести пароль (PIN-код). Такая аутентификация называется двухфакторной. Существуют реальные системы и с трехфакторной аутентификацией.

В ряде случаев требуется и взаимная аутентификация - когда оба участника информационного обмена проверяют друг друга. Например, перед передачей удаленному серверу каких-либо важных данных пользователь должен убедиться, что это именно тот сервер, который ему необходим.

Удаленная аутентификация

В случае удаленной аутентификации (скажем, пользователь намерен получить доступ к удаленному почтовому серверу для проверки своей электронной почты) существует проблема передачи аутентификационной информации по недоверенным каналам связи (через Интернет или локальную сеть). Чтобы сохранить в тайне уникальную информацию, при пересылке по таким каналам используется множество протоколов аутентификации. Рассмотрим некоторые из них, наиболее характерные для различных применений.

Доступ по паролю

Простейший протокол аутентификации - доступ по паролю (Password Access Protocol, PAP): вся информация о пользователе (логин и пароль) передается по сети в открытом виде (рис. 1). Полученный сервером пароль сравнивается с эталонным паролем данного пользователя, который хранится на сервере. В целях безопасности на сервере чаще хранятся не пароли в открытом виде, а их хэш-значения.



Рис. 1. Схема протокола PAP.

Данная схема имеет весьма существенный недостаток: любой злоумышленник, способный перехватывать сетевые пакеты, может получить пароль пользователя с помощью простейшего анализатора пакетов типа sniffer. А получив его, злоумышленник легко пройдет аутентификацию под именем владельца пароля.

По сети в процессе аутентификации может передаваться не просто пароль, а результат его преобразования - скажем, тот же хэш пароля. К сожалению, это не устраняет описанный выше недостаток - злоумышленник с тем же успехом может перехватить хэш пароля и применять его впоследствии.

Недостатком данной схемы аутентификации можно считать и то, что любой потенциальный пользователь системы должен предварительно зарегистрироваться в ней - как минимум ввести свой пароль для последующей аутентификации.

Запрос-ответ

В семейство протоколов, называемых обычно по процедуре проверки "запрос-ответ", входит несколько протоколов, которые позволяют выполнить аутентификацию пользователя без передачи информации по сети. К протоколам семейства "запрос-ответ" относится, например, один из наиболее распространенных - протокол CHAP (Challenge-Handshake Authentication Protocol).

Процедура проверки включает как минимум четыре шага (рис. 2):

· пользователь посылает серверу запрос на доступ, включающий его логин;

· сервер генерирует случайное число и отправляет его пользователю;

· пользователь шифрует полученное случайное число симметричным алгоритмом шифрования на своем уникальном, результат зашифрования отправляется серверу;

· сервер расшифровывает полученную информацию на том же ключе и сравнивает с исходным случайным числом. При совпадении чисел пользователь считается успешно аутентифицированным, поскольку признается владельцем уникального секретного ключа.

Рис. 2. Схема протокола аутентификации типа "запрос-ответ".

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

Основной недостаток подобных систем аутентификации - необходимость иметь на локальном компьютере клиентский модуль, выполняющий шифрование. Это означает, что, в отличие от протокола PAP, для удаленного доступа к требуемому серверу годится только ограниченное число компьютеров, оснащенных таким клиентским модулем.

Однако в качестве клиентского компьютера может выступать и смарт-карта либо аналогичное "носимое" устройство, обладающее достаточной вычислительной мощностью, например, мобильный телефон. В таком случае теоретически допустима аутентификация и получение доступа к серверу с любого компьютера, оснащенного устройством чтения смарт-карт, с мобильного телефона или КПК.

Протоколы типа "запрос-ответ" легко "расширяются" до схемы взаимной аутентификации (рис. 3). В этом случае в запросе на аутентификацию пользователь (шаг 1) посылает свое случайное число (N1). Сервер на шаге 2, помимо своего случайного числа (N2), должен отправить еще и число N1, зашифрованное соответствующим ключом. Тогда перед выполнением шага 3 пользователь расшифровывает его и проверяет: совпадение расшифрованного числа с N1 указывает, что сервер обладает требуемым секретным ключом, т. е. это именно тот сервер, который нужен пользователю. Такая процедура аутентификации часто называется рукопожатием.

Рис. 3. Схема протокола взаимной аутентификации.

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

Следует отметить, что вместо симметричного шифрования в протоколах данного семейства может применяться и асимметричное шифрование, и электронная цифровая подпись. В таких случаях схему аутентификации легко расширить на неограниченное число пользователей, достаточно применить цифровые сертификаты в рамках инфраструктуры открытых ключей.



Практическая работа № 2. Протокол Kerberos

Протокол Kerberos, достаточно гибкий и имеющий возможности тонкой настройки под конкретные применения, существует в нескольких версиях. Мы рассмотрим упрощенный механизм аутентификации, реализованный с помощью протокола Kerberos версии 5 (рис. 1):

Рис. 1. Схема протокола Kerberos.

Прежде всего стоит сказать, что при использовании Kerberos нельзя напрямую получить доступ к какому-либо целевому серверу. Чтобы запустить собственно процедуру аутентификации, необходимо обратиться к специальному серверу аутентификации с запросом, содержащим логин пользователя. Если сервер не находит автора запроса в своей базе данных, запрос отклоняется. В противном случае сервер аутентификации формирует случайный ключ, который будет использоваться для шифрования сеансов связи пользователя с еще одним специальным сервером системы: сервером предоставления билетов (Ticket-Granting Server, TGS). Данный случайный ключ (обозначим его Ku-tgs) сервер аутентификации зашифровывает на ключе пользователя (Kuser) и отправляет последнему. Дополнительная копия ключа Ku-tgs с рядом дополнительных параметров (называемая билетом) также отправляется пользователю зашифрованной на специальном ключе для связи серверов аутентификации и TGS (Ktgs). Пользователь не может расшифровать билет, который необходим для передачи серверу TGS на следующем шаге аутентификации.

Следующее действие пользователя - запрос к TGS, содержащий логин пользователя, имя сервера, к которому требуется получить доступ, и тот самый билет для TGS. Кроме того, в запросе всегда присутствует метка текущего времени, зашифрованная на ключе Ku-tgs. Метка времени нужна для предотвращения атак, выполняемых повтором перехваченных предыдущих запросов к серверу. Подчеркнем, что системное время всех компьютеров, участвующих в аутентификации по протоколу Kerberos, должно быть строго синхронизировано.

В случае успешной проверки билета сервер TGS генерирует еще один случайный ключ для шифрования сеансов связи между пользователем, желающим получить доступ, и целевым сервером (Ku-serv). Этот ключ шифруется на ключе Kuser и отправляется пользователю. Кроме того, аналогично шагу 2, копия ключа Ku-serv и необходимые целевому серверу параметры аутентификации (билет для доступа к целевому серверу) посылаются пользователю еще и в зашифрованном виде (на ключе для связи TGS и целевого сервера - Kserv).

Теперь пользователь должен послать целевому серверу полученный на предыдущем шаге билет, а также метку времени, зашифрованную на ключе Ku-serv. После успешной проверки билета пользователь наконец-то считается аутентифицированным и может обмениваться информацией с целевым сервером. Ключ Ku-serv, уникальный для данного сеанса связи, часто применяется и для шифрования пересылаемых в этом сеансе данных.

В любой системе может быть несколько целевых серверов. Если пользователю необходим доступ к нескольким из них, он снова формирует запросы к серверу TGS - столько раз, сколько серверов нужно ему для работы. Сервер TGS генерирует для каждого из таких запросов новый случайный ключ Ku-serv, т. е. все сессии связи с различными целевыми серверами защищены при помощи разных ключей.

Процедура аутентификации по протоколу Kerberos выглядит достаточно сложной. Однако не стоит забывать, что все запросы и зашифровывание их нужными ключами автоматически выполняет ПО, установленное на локальном компьютере пользователя. Вместе с тем необходимость установки достаточно сложного клиентского ПО - несомненный недостаток данного протокола. Впрочем, сегодня поддержка Kerberos встроена в наиболее распространенные ОС семейства Windows, начиная с Windows 2000, что нивелирует данный недостаток.

Второй недостаток - необходимость в нескольких специальных серверах (доступ к целевому серверу обеспечивают как минимум еще два, сервер аутентификации и TGS). Однако в системах с небольшим числом пользователей все три сервера (аутентификации, TGS и целевой) могут физически совмещаться на одном компьютере.

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



Практическая работа № 3. Протокол PPTP

Протокол PPTP (Point-to-Point-Tunneling Protocol), разработанный Microsoft при поддержке других компаний, представляет собой расширение протокола PPP (Point-to-Point Protocol) для создания защищенных виртуальных каналов при доступе удаленных пользователей к локальным сетям через Internet. Он предусматривает создание криптозащищенного туннеля на канальном уровне модели OSI как в случае прямого соединения удаленного компьютера с публичной сетью, так и в случае подсоединения его к публичной сети по телефонной линии через провайдера.

Данный протокол был представлен в организацию Internet Engineering Task Force (IETF) в качестве претендента на стандартный протокол создания защищенного канала при доступе удаленных пользователей к локальным сетям через публичные сети (в первую очередь через Internet). PPTP получил статус проекта стандарта Internet, однако, несмотря на широкое распространение, в качестве стандарта так и не был утвержден. Сейчас рабочая группа IETF рассматривает возможность принятия в качестве стандарта протокол L2TP (Layer 2 Tunneling Protocol), который объединяет лучшие стороны протокола PPTP и подобного протокола L2F (Layer 2 Forwarding), предложенного компанией Cisco Systems.

Для удаленного пользователя, подключенного через публичную IP-сеть к серверу удаленного доступа (Remote Access Service - RAS) локальной сети, PPTP имитирует нахождение компьютера этого пользователя во внутренней сети посредством туннелирования пакетов сообщений. Данные через туннель переносятся с помощью стандартного протокола удаленного доступа PPP, который в протоколе PPTP используется не только для связи компьютера удаленного пользователя с RAS провайдера Internet, но и для взаимодействия с RAS локальной сети через туннель. Для передачи данных применяются IP-пакеты, содержащие инкапсулированные PPP-пакеты. Инкапсулированные PPP-пакеты в свою очередь включают зашифрованные инкапсулированные исходные пакеты (IP, IPX или NetBEUI), предназначенные для взаимодействия между компьютером удаленного пользователя и локальной сетью. Пакеты, циркулирующие в рамках сессии PPTP, имеют следующую структуру:

o заголовок канального уровня, используемый внутри Internet, например, заголовок кадра Ethernet;

o заголовок IP;

o заголовок GRE (Generic Routing Encapsulation - общий метод инкапсуляции для маршрутизации);

o исходный пакет PPP, включающий пакет IP, IPX или NetBEUI.

Для указания сведений о том, что внутри пакета IP находится инкапсулированный пакет РРР, используется стандартный для Internet заголовок протокола GRE v.2, используемый при инкапсуляции различного типа.

Описанный способ инкапсуляции обеспечивает независимость от протоколов сетевого уровня модели OSI и позволяет осуществлять защищенный удаленный доступ через публичные IP-сети к любым локальным сетям (IP, IPX или NetBEUI).

Технология создания защищенного виртуального канала по протоколу PPTP так же предусматривает аутентификацию удаленного пользователя.

Для аутентификации могут использоваться различные протоколы. В реализации PPTP, включенной в Windows 98/NT поддерживаются протоколы аутентификации PAP (Password Authentication Protocol - протокол распознавания пароля) и CHAP (Challenge-Handshaking Authentication Protocol - протокол распознавания при рукопожатии). При использовании протокола PAP идентификаторы и пароли передаются по линии связи в незашифрованном виде. При использовании же протокола CHAP каждый пароль для передачи по линии связи шифруется на основе случайного числа, полученного от сервера. Такая технология обеспечивает также защиту от повторного использования злоумышленником перехваченных пакетов с зашифрованным паролем.

Программное обеспечение удаленного доступа, реализующее PPTP, может использовать любой стандарт криптографического закрытия передаваемых данных. Например, сервер удаленного доступа Windows NT использует стандарт RC4 и в зависимости от версии 40- или 128-разрядные сеансовые ключи, которые генерируются на основе пароля пользователя.

В протоколе PPTP определено три схемы его применения: одна схема - для случая прямого соединения компьютера удаленного пользователя через Internet к некой локальной сети и две - для случая подсоединения удаленного компьютера к Internet по телефонной линии через провайдера.

При прямом соединении компьютера удаленного пользователя с сетью Internet (см. Рис. 3), например, при доступе из локальной сети, напрямую подключенной к Internet, пользователь устанавливает удаленное соединение с помощью клиентской части сервиса удаленного доступа. Он обращается к серверу удаленного доступа локальной сети, указывая его IP-адрес, и устанавливает с ним связь по протоколу PPTP. Функции сервера удаленного доступа может выполнять и пограничный маршрутизатор локальной сети. Протокол PPTP определяет некоторое количество служебных сообщений, которыми обмениваются взаимодействующие стороны. Служебные сообщения передаются по протоколу TCP. После успешной аутентификации начинается процесс защищенного информационного обмена.

Рис. 3. Схема туннелирования при прямом соединении удаленного компьютера с Internet

В этом варианте на компьютере удаленного пользователя должны быть установлены клиент RAS и драйвер PPTP, которые входят в состав Windows 98/NT, а на сервере удаленного доступа локальной сети - сервер RAS и драйвер PPTP, входящие в состав Windows NT Server. Внутренние серверы локальной сети не должны поддерживать протокол PPTP, так как пограничный маршрутизатор извлекает кадры РРР из пакетов IP и посылает их по сети в необходимом формате - IP, IPX или NetBIOS.

Для случая подсоединения удаленного компьютера к Internet по телефонной линии через провайдера предусмотрено две схемы (см. Рис. 4).

Первая схема рассчитана на поддержание защищенного канала между сервером удаленного доступа ISP (Internet Service Provider - провайдера Internet) и пограничным маршрутизатором корпоративной сети.

Рис.4. Защищенный канал "провайдер-маршрутизатор корпоративной сети" на основе протокола PPTP

В этом варианте компьютер удаленного пользователя не должен поддерживать протокол PPTP. Он связывается с сервером удаленного доступа RAS, установленного у ISP, с помощью стандартного протокола PPP и проходит первую аутентификацию у провайдера. RAS ISP должен поддерживать протокол PPTP. По имени пользователя RAS ISP должен найти в базе учетных данных пользователей IP-адрес маршрутизатора, являющегося пограничным маршрутизатором корпоративной сети данного пользователя. С этим маршрутизатором RAS ISP устанавливает сессию по протоколу PPTP. Протокол PPTP определяет некоторое количество служебных сообщений, которыми обмениваются взаимодействующие стороны, служебные сообщения передаются по протоколу TCP. RAS ISP передает маршрутизатору корпоративной сети идентификатор пользователя, по которому маршрутизатор снова аутентифицирует пользователя по протоколу CHAP. Если пользователь прошел вторичную аутентификацию (она для него прозрачна), то RAS ISP посылает ему сообщение об этом по протоколу РРР и пользователь начинает посылать свои данные в RAS ISP по протоколу IP, IPX или NetBIOS, упаковывая их в кадры РРР. RAS ISP осуществляет инкапсуляцию кадров РРР в пакеты IP, указывая в качестве адреса назначения адрес пограничного маршрутизатора, а в качестве адреса источника - свой собственный IP-адрес. Пакеты РРР шифруются с помощью секретного ключа, в качестве которого используется дайджест от пароля пользователя, который хранится в базе учетных данных RAS ISP для аутентификации по протоколу CHAP.

Рис. 5. Схема туннелирования при подсоединении удаленного компьютера к Internet по телефонной линии через провайдера

Описанная схема не находит широкого применения, так протокол PPTP реализован в основном в продуктах компании Microsoft - в клиентской и серверной частях RAS Windows NT 4.0, а также в клиентской части RAS Windows 98. В качестве сервера удаленного доступа провайдеры чаще всего используют более мощные средства, чем RAS Windows NT. Кроме того, данная схема не обеспечивает высокой степени безопасности, так как между компьютером удаленного пользователя и провайдером Internet данные передаются в незащищенном виде.

Для случая подсоединения удаленного компьютера к Internet по телефонной линии через провайдера более широкое применение получила вторая схема (см. Рис. 3.5), когда криптозащищенный туннель образуется между конечными точками взаимодействия. Пользователь дважды устанавливает удаленное соединение с помощью клиентской части сервиса удаленного доступа, например, утилиты Dial-Up Networking из Windows 98/NT. В первый раз он звонит по модему на сервер удаленного доступа провайдера и устанавливает с ним связь по протоколу PPP, проходя аутентификацию одним из способов, поддерживаемых провайдером - по протоколам PAP, CHAP или с помощью терминального диалога.

После успешной аутентификации у провайдера, пользователь устанавливает соединение с сервером удаленного доступа локальной сети, указывая его IP-адрес. Далее устанавливается сессия по протоколу PPTP между удаленным компьютером и RAS локальной сети. Сервер удаленного доступа локальной сети проверяет подлинность пользователя на основе своей базы учетных данных. В случае успешной аутентификации начинается процесс защищенного информационного обмена. Для сокращения ручного труда Microsoft предлагает пользоваться возможностями языка написания сценариев (языка скриптов) в RAS Windows 98/NT.

Для взаимодействия между пограничными устройствами криптозащищенного туннеля в протоколе PPTP предусмотрены управляющие сообщения, предназначенные для установки, поддержки и разрыва туннеля. Обмен управляющими сообщениями выполняется по TCP-соединению, устанавливаемому между клиентом и сервером PPTP. Пакеты, передаваемые через это соединение, помимо заголовка канального уровня, содержат заголовок протокола IP, заголовок протокола TCP и управляющее сообщение PPTP в области данных пакета. Если компьютер удаленного пользователя не имеет поддержки PPTP, что характерно для схемы создания защищенного канала между сервером удаленного доступа провайдера Internet и пограничным маршрутизатором локальной сети, то в процессе обмена управляющими сообщениями этот компьютер не участвует. Функции клиента PPTP в данном случае возложены на сервер удаленного доступа провайдера Internet.

При обмене управляющими сообщениями PPTP используется логический порт протокола TCP с номером 1723, а при передаче инкапсулированных пакетов PPP в заголовке IP устанавливается идентификатор протокола, равный 47. Эти соглашения позволяют использовать технологию PPTP совместно с межсетевыми экранами. Для повышения безопасности следует с помощью межсетевого экрана локальной сети блокировать любой трафик, отличный от трафика PPTP.



Практическая работа № 4. Протокол L2F

Протокол L2F (Layer-2 Forwarding) разработан компанией Cisco Systems при поддержке компаний Shiva и Northern Telecom в качестве альтернативы протоколу PPTP для создания защищенных виртуальных сетей на канальном уровне модели OSI. В отличие от PPTP, данный протокол характеризуется более высоким удобством в использовании для провайдеров Internet, а также поддержкой разных сетевых протоколов. В соответствии с протоколом L2F для связи компьютера удаленного пользователя с сервером провайдера могут применяться различные протоколы удаленного доступа - PPP, SLIP и другие. Публичная сеть, используемая для переноса данных через туннель, может функционировать не только по протоколу IP, но и на основе других протоколов, например, протокола X.25. Первая реализация протокола L2F выполнена для сетей TCP/IP.

Помимо ориентации на различные протоколы информационного обмена, при разработке протокола L2F также преследовались следующие цели:

· гибкость аутентификации, предусматривающая отсутствие жесткой привязки к конкретным протоколам подтверждения подлинности;

· прозрачность для конечных систем - ни удаленная система, ни рабочие станции локальной сети не должны иметь специальное программное обеспечение, чтобы использовать защитный сервис;

· прозрачность для посредников:

§ авторизация должна выполняться так, как в случае непосредственного подключения пользователей к серверу удаленного доступа локальной сети;

§ адрес сервера удаленного доступа должен назначаться не сервером провайдера, а сервером локальной сети;

· полнота аудита, предусматривающая регистрацию событий по доступу к серверу локальной сети не только сервером удаленного доступа этой сети, но и сервером провайдера.

Можно выделить три типа протоколов, участвующих в образовании защищенного туннеля:

· исходный инкапсулируемый протокол - это протокол, по которому функционирует локальная сеть и который используется для непосредственного взаимодействия с этой локальной сетью, например, протокол IP, IPX или NetBEUI;

· протокол-пассажир, в который инкапсулируется исходный протокол и который в свою очередь требуется инкапсулировать при удаленном доступе через публичную сеть (в качестве данного протокола рекомендован протокол PPP);

· инкапсулирующий протокол - это управляющий протокол, который используется для создания, поддержания и разрыва туннеля (в данном случае в качестве такого протокола выступает протокол L2F);

· протокол провайдера, который используется для переноса инкапсулируемых протоколов (исходного протокола и протокола-пассажира); наиболее гибким и популярным протоколом провайдера является протокол IP.



Протокол рассылки канального уровня L2F (layer 2 Forwarding Protocol) позволяет организовать туннелирование канального уровня протоколами вышележащих уровней. Использование таких туннелей позволяет избавиться от связи местоположения изначального сервера dial-up с местом завершения коммутируемого соединения и обеспечения доступа в сеть.

Формат пакетов L2F показан на рисунке.



Формат пакетов L2F

Версия

· Старшая часть номера версии программы L2F, создавшей пакет.

Протокол

· Указывает протокол, передаваемый в пакетах L2F.

Номер

· Порядковый номер пакета присутствует в заголовке, если флаг S установлен.

Идентификатор мультиплексирования

· Идентификатор мультиплексирования служит для обозначения отдельных соединений в туннеле.

Идентификатор клиента

· Идентификатор клиента (CLID) помогает демультиплексировать туннели в конечных точках.

Размер

· Размер (в октетах) целого пакета с учетом заголовка, всех полей и содержимого.

Смещение содержимого

· Указывает смещение начала содержимого пакета от конца заголовка L2F (в байтах). Это поле присутствует в пакетах с установленным флагом F.

Ключ пакета

· Поле ключа используется в пакетах с установленным флагом K и используется в процессе аутентификации.

Контрольная сумма

· Контрольная сумма пакета, используемая при установке флага C.

Формирование виртуального канала по протоколу L2F выполняется в соответствии со следующими этапами (см. Рис. 1).

Этап 1. Удаленный пользователь устанавливает соединение с сервером RAS (Remote Access Service) провайдера по протоколу PPP. Далее RAS провайдера начинает процесс аутентификацию на основе используемого протокола (CHAP, PAP или другого). В соответствии с протоколом CHAP после установления соединения сервер RAS провайдера отправляет пользователю пакет «Вызов» (Challenge), содержащее псевдослучайное число. Пользователь отвечает пакетом «Отклик» (Response), содержащим идентификатор пользователя, а также число, сгенерированное с помощью односторонней хэш-функции на основе псевдослучайного числа и пароля пользователя.



Рис. 1. Схема взаимодействия по протоколу L2F

Этап 2. В процессе аутентификации RAS провайдера интерпретирует только идентификатор пользователя, чтобы определить необходимость создания виртуального канала, а в случае необходимости - найти адрес пограничного маршрутизатора требуемой локальной сети. Идентификатор пользователя, а также другие данные, полученные на этой стадии аутентификации, сохраняются для передачи серверу удаленного доступа локальной сети, который и будет осуществлять окончательную проверку подлинности пользователя. В качестве таких данных для протокола CHAP выступают значение хэш-функции от пароля и псевдослучайного числа, а также само это псевдослучайное число,

Необходимость создания виртуального канала определяется на основе базы данных, которая ведется провайдером на своем сервере безопасности.

Для возможности быстрого определения адреса пограничного маршрутизатора требуемой локальной сети предполагается, что идентификаторы пользователей будут составными, например, nurbek@tuit.uz. В левой части от символа `@' указывается зарегистрированное в локальной сети имя пользователя, а в правой части - доменный адрес пограничного маршрутизатора локальной сети, являющегося и сервером удаленного доступа. Если же процедура определения адресов по составным идентификаторам не используются, то провайдер на своем сервере безопасности должен вести базу данных, в которой идентификаторы пользователей отображаются на IP-адреса пограничных маршрутизаторов локальных сетей.

Этап 3. Если сервис виртуального канала необходим, то после определения адреса пограничного маршрутизатора локальной сети проверяется существование туннеля к этому пограничному маршрутизатору. Если туннель отсутствует, то он создается. Спецификации протокола L2F требуют, чтобы туннель обеспечивал соединение «точка-точка». В первой реализации L2F для формирования такого соединения выбран протокол UDP.

После создания туннеля сервер RAS провайдера назначает неиспользуемый идентификатор мультиплексируемого канала (Multiplex ID - MID) новому виртуальному соединению, генерирует для него псевдослучайный ключ и отправляет серверу удаленного доступа локальной сети сообщение об установлении новой dial-up сессии, включающее также информацию для аутентификации. Сгенерированный псевдослучайный ключ используется для защиты пакетов сообщений от подмены.

Этап 4. На основе информации, полученной от сервера RAS провайдера, сервер RAS локальной сети выполняет проверку подлинности пользователя и в зависимости от полученных результатов принимает или отвергает новую сессию. Проверка подлинности осуществляется на основе взаимодействия с сервером безопасности локальной сети.

Так, если для аутентификации пользователя применяется протокол CHAP, то в сообщении об установлении новой dial-up сессии, помимо других служебных данных, серверу RAS локальной сети передается идентификатор пользователя, значение хэш-функции от пароля и псевдослучайного числа-вызова, а также само это псевдослучайное число. Сервер RAS локальной сети по полученному идентификатору пользователя извлекает из базы данных своего сервера безопасности зашифрованное эталонное значение пароля и на основе этого значения, а также полученного псевдослучайного числа-вызова определяет эталонное значение хэш-функции. В случае, если эталонное значение хэш-функции совпадает с полученным, то аутентификация считается успешной. В противном случае пользователь не допускается в локальную сеть и новая сессия отвергается.

Этапы 5 и 6. Если сервер RAS локальной сети принимает новую сессию, то он создает для нее виртуальный канал по протоколу PPP (этап 5), подобно тому, как это происходит при непосредственном звонке на сервер удаленного доступа. Сервер удаленного доступа провайдера может выполнять регистрацию событий по созданию и разрыву виртуального канала (этап 6).

Этап 7. После создания виртуального канала кадры протокола PPP передаются в обоих направлениях. На сервере RAS провайдера и локальной сети кадры PPP для передачи по Internet очищаются от стартовых и стоповых флагов, инкапсулируются по протоколу L2F в пакеты IP и отправляются. При приеме пакетов IP с инкапсулированными кадрами PPP в пограничных точках Internet серверы RAS провайдера и локальной сети выполняют обратную процедуру. Так функционирует эмулируемое PPP-соединение «точка-точка», где конечными точками являются сетевая программа удаленного пользователя и программа, поддерживающая PPP на сервере RAS локальной сети.

Для криптографического закрытия трафика между конечными точками созданного виртуального канала предполагается использовать протокол IPSec.

Описанные этапы формирования виртуального канала по протоколу L2F, а также схемы использования протокола PPTP позволяют выделить важные отличия данной технологии от использования традиционной службы удаленного доступа через Internet.

В случае традиционной службы удаленного доступа аутентификация пользователей осуществляется самим сервером провайдера. При использовании технологии L2F сервер удаленного доступа провайдера использует аутентификацию только для того, чтобы определить необходимость создания виртуального канала и найти адрес сервера удаленного доступа требуемой локальной сети. Как в протоколе L2F, так и в протоколе PPTP окончательная проверка подлинности выполняется сервером RAS локальной сети после того, как сервер провайдера с ним связывается. Сервер удаленного доступа локальной сети проводит аутентификацию с помощью стандартных протоколов аутентификации удаленного доступа на основании информации, полученной от сервера провайдера. Так как аутентификацию проводит сервер локальной сети, то и политику доступа диктует служба безопасности этой сети, а не провайдер Internet. Такой подход обеспечивает более высокий уровень безопасности, так как функции защиты в данном случае возложены на того, кто в этом заинтересован. Провайдер Internet может быть неблагонадежным или халатно относиться к своим обязанностям. Кроме того, технология L2F является более гибкой, так как в случае ее полной реализации не требует привязки учетных данных об удаленных пользователях к провайдерам Internet.

К недостатку протокола L2F можно отнести то, что для текущей (четвертой) версии протокола IP не предусматривается создание криптозащищенного туннеля между конечными точками информационного взаимодействия. Виртуальный защищенный канал может быть создан только между сервером удаленного доступа провайдера и пограничным маршрутизатором локальной сети, а участок между компьютером удаленного пользователя и сервером провайдера остается открытым.



Практическая работа № 5. Особенности протокола L2TP

Протокол L2TP (Layer-2 Tunneling Protocol - L2TP) разработан в организации Internet Engineering Task Force (IETF) при поддержке компаний Microsoft и Cisco Systems как протокол защищенного туннелирования PPP-трафика через сети общего назначения с произвольной средой. Работа над данным протоколом велась на основе протоколов PPTP и L2F, и он вобрал в себя лучшие возможности обоих проектов. L2TP, в отличие от PPTP, не привязан к протоколу IP, а потому может быть использован в сетях с коммутацией пакетов, например, в сетях ATM. Кроме того, L2TP предусматривает управление потоками данных, отсутствующее в L2F. Главное же, по мнению разработчиков, то, что новый протокол должен стать общепринятым стандартом, признаваемым всеми производителями.

Чтобы понять суть концепции L2TP, нужно представлять цели, которые преследовали компании Microsoft и Cisco при разработке РРТР и L2F.

В соответствии с целями, которые преследовались при разработке РРТР и L2F, различные организации должны были получить возможность делегировать функции безопасного удаленного доступа провайдерам Internet. Это, в свою очередь, позволило бы снизить затраты на администрирование и приобретение аппаратных средств, так как локальные сети этих организаций смогли бы обойтись без множества модемов и дополнительных телефонных каналов. В обоих протоколах поставленная цель была достигнута. И L2F, и РРТР позволяют провайдерам Internet проводить удаленные сеансы по протоколу РРР, используя для аутентификации запросы к серверам безопасности локальных сетей.

Различия между L2F и РРТР объясняются специализацией их разработчиков. Cisco производит аппаратные маршрутизаторы для сетевой инфраструктуры, тогда как Microsoft выпускает операционные системы. Для работы провайдеров с L2F нужно, чтобы их маршрутизаторы и серверы удаленного доступа поддерживали этот протокол. Что касается протокола РРТР, то провайдеры не обязательно должны иметь средства организации туннелей, так как туннели могут формироваться специальным программным обеспечением конечных точек взаимодействия - компьютеров удаленных пользователей и серверов удаленного доступа локальных сетей. Тем не менее, L2F по сравнению с РРТР имеет несколько преимуществ. Так, PPTP требует применения маршрутизации на базе IP, тогда как L2F не привязан к конкретным протоколам сетевого уровня, используемым для транспортировки PPP-кадров.

В гибридном протоколе L2TP не только объединены лучшие черты протоколов PPTP и L2TP, но и добавлены новые функции.

Как и РРТР, новая спецификация не нуждается во встроенной аппаратной поддержке, хотя оборудование, специально предназначенное для нее, повысит производительность и защищенность системы. В L2TP есть ряд отсутствующих в спецификации PPTP функций защиты, включая возможность работы с протоколом IPsec.

Наследственные черты L2F видны в том, что протокол не привязан к среде IP и с таким же успехом способен работать в любых сетях с коммутацией пакетов, например, в сетях ATM или в сетях с ретрансляцией кадров (frame relay).

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

По существу протокол L2TP представляет собой расширение PPP-протокола функциями аутентификации удаленных пользователей, установки защищенного виртуального соединения, а также управлением потоками данных. В соответствии с протоколом L2TP (см. Рис. 7) в качестве сервера удаленного доступа провайдера должен выступать концентратор доступа (Access Concentrator), который реализует клиентскую часть протокола L2TP и обеспечивает пользователю сетевой доступ к его локальной сети через Internet. Роль сервера удаленного доступа локальной сети должен выполнять сетевой сервер L2TP (L2TP Network Server), функционирующий на любых платформах, совместимых с протоколом PPP.

Пары атрибут	значение AVP (Attribute Value Pair) Объединение уникального атрибута (представляемого в виде целого числа) и действительного значения этого атрибута. Пара AVP имеет переменную длину. Несколько AVP образуют управляющие сообщения, которые используются при установлении, поддержке и ликвидации туннеля.
Вызов	Соединение (или попытка соединения) между удаленной системой и LAC (L2TP Access Concentrator). Например, телефонный вызов через обычную коммутируемую телефонную сеть PSTN. Вызов (входящий или исходящий), который успешно осуществил связь между удаленной системой и LAC, реализуется в ходе L2TP-сессии при условии, что туннель между LAC и LNS (L2TP Network Server) уже создан.
Вызванный номер	Телефонный номер, использованный для связи с получателем вызова.
Вызывающий номер	Телефонный номер, откуда пришел вызов.
CHAP	Challenge Handshake Authentication Protocol [RFC1994], криптографический PPP-протокол для аутентификации вызова/отклика, в котором пароль не передается открытым текстом.
Управляющее соединение	Управляющее соединение работает в пределах имеющейся полосы туннеля и служит для установления, аннулирования и поддержания сессий и самого туннеля.
Управляющие сообщения	Управляющими сообщениями обмениваются LAC и LNS, работающие в пределах имеющейся полосы туннеля. Управляющие сообщения контролируют сам туннель и реализуемые через него сессии.
Цифровой канал	Коммутируемый канал, по которому передаются цифровые данные в обоих направлениях.
DSLAM	Digital Subscriber Line (DSL) Access Module (модуль доступа клиентов к цифровым линиям). Сетевой прибор, используемый для реализации DSL-сервиса. Это обычно концентратор индивидуальных DSL-линий, размещенный в центральном офисе (CO), или местный коммутатор.
Входящий вызов	Вызов, полученный LAC для туннелирования в LNS.
Концентратор доступа L2TP (LAC)	Узел, который действует в качестве одной из сторон L2TP-туннеля и является партнером для LNS (L2TP Network Server). LAC размещается между LNS и удаленной системой, переадресуя им пакеты. Пакеты, посланные от LAC к LNS, требуют туннелирования с помощью протокола L2TP, как это определено в данном документе. Соединение между LAC и удаленной системой является локальным или осуществляется через канал PPP.
Сетевой сервер L2TP (LNS)	Узел, который работает в качестве одного из концов L2TP туннеля, и является партнером для LAC (L2TP Access Concentrator). LNS является логической терминальной точкой PPP-сессии, которая организует туннель между удаленной системой и LAC.
Домен управления (MD)	Сеть или сети, управляемые общей администрацией administration, политикой или системой. Например, доменом управления LNS может быть корпоративная сеть, которую он обслуживает. Доменом управления LAC может быть сервис-провайдер Интернет, которым он управляет.
Сервер доступа к сети (NAS)	Прибор, предоставляющий доступ к локальной сети для пользователей удаленной сети, такой как общедоступная коммутируемая телефонная сеть (PSTN). NAS может выполнять функцию LAC, LNS или и того и другого.
Исходящий вызов	Вызов, сделанный LAC, для туннелирования в LNS.
Партнер	При использовании в контексте L2TP, партнер относится к LAC или LNS. Партнером LAC является LNS и наоборот. При использовании в контексте PPP, партнером является любая из сторон PPPсоединения.
POTS	Plain Old Telephone Service (обычная телефонная служба).
Удаленная система	Оконечная система или маршрутизатор, соединенный с удаленной сетью (т.e. PSTN), которая является инициатором или получателем вызова. Относится также к клиенту, подключающемуся через коммутируемую телефонную сеть (dial-up).
Сессия	Протокол L2TP ориентирован на соединение. LNS и LAC поддерживают состояния для каждого вызова, который инициирован или воспринят LAC. Сессия L2TP формируется между LAC и LNS, когда создано соединение точка-точка PPP между удаленной системой и LNS. Дейтограммы, относящиеся к соединению PPP, пересылаются по туннелю, организованному между LAC и LNS. Существует полное соответствие между сессиями L2TP и сопряженными с ними вызовами.
Туннель	Туннель между LAC и LNS. Туннель состоит из управляющего соединения и нуля или более сессий L2TP. Туннель передает инкапсулированные дейтограммы PPP и управляющие сообщения между LAC и LNS.
Сообщение с нулевой длиной тела (ZLB)	Управляющий пакет, имеющий только заголовок L2TP. ZLB-сообщения используются в качестве откликов в управляющем канале

На диаграмме (рис. 1.) показана схема работы протокола L2TP. Целью здесь является туннелирование кадров PPP между удаленной системой или клиентом LAC и LNS, размещенной в LAN.

Рис. 1 Схема работы протокола L2TP

Удаленная система инициирует PPP-соединение с LAC через коммутируемую телефонную сеть PSTN. LAC затем прокладывает туннель для PPP-соединения через Интернет, Frame Relay или ATM к LNS, посредством чего осуществляется доступ к исходной LAN (Home LAN). Адреса удаленной системе предоставляются исходной LAN через согласование с PPP NCP. Аутентификация, авторизация и аккоунтинг могут быть предоставлены областью управления LAN, как если бы пользователь был непосредственно соединен с сервером сетевого доступа NAS.

LAC-клиент (ЭВМ, которая исполняет программу L2TP) может также участвовать в туннелировании до исходной LAN без использования отдельного LAC. В этом случае, ЭВМ, содержащая программу LAC клиента, уже имеет соединение с Интернет. Затем создается "виртуальное" PPP-соединение и локальная программа L2TP LAC формирует туннель до LNS. Как и в выше описанном случае, адресация, аутентификация, авторизация и аккоунтинг будут обеспечены областью управления исходной LAN.

L2TP использует два вида пакетов, управляющие и информационные сообщения. Управляющие сообщения используются при установлении, поддержании и аннулировании туннелей и вызовов. Информационные сообщения используются для инкапсуляции PPP-кадров пересылаемых по туннелю. Управляющие сообщения используют надежный контрольный канал в пределах L2TP, чтобы гарантировать доставку. Информационные сообщения если происходит их потеря, не пересылаются повторно.

PPP кадры
L2TP Информационные сообщения		L2TP Управляющие сообщения
L2TP Информационный канал (ненадежный)		L2TP Канал управления (надежный)
Транспортировка пакетов (UDP, FR, ATM, etc.)

Рис. 2. Структура протокола L2TP

На рис. 3 показано взаимоотношение PPP-кадров и управляющих сообщений по управляющему и информационному каналам L2TP. PPP-кадры передаются через ненадежный канал данных, инкапсулированные сначала в L2TP, а затем в транспортные пакеты, такие как UDP, Frame Relay, ATM и т.д.. Управляющие сообщения посылаются через надежный управляющий канал L2TP, который передает пакеты в пределах того же пакетного транспорта.

Протокольные операции

Необходимая процедура установления PPP-сессии туннелирования L2TP включает в себя два этапа:

- Установление управляющего канала для туннеля, и

- Формирование сессии в соответствии с запросом входящего или исходящего вызова.

Туннель и соответствующий управляющий канал должны быть сформированы до инициализации входящего или исходящего вызовов. L2TP-сессия должна быть реализована до того, как L2TP сможет передавать PPP-кадры через туннель. В одном туннеле могут существовать несколько сессий между одними и теми же LAC и LNS.

Рис. 3 Прохождение PPP-кадров

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

L2TP включает в себя простую, опционную, CHAP-подобную [RFC1994] систему аутентификации туннеля в процессе установления \управляющего соединения. Если LAC или LNS хочет идентифицировать партнера, с которым контактирует или контактировал посредством AVP приглашения, включенного в SCCRQ или SCCRP-сообщения. Если в SCCRQ или SCCRP получена AVP приглашения, AVP отклика приглашения должна быть послана в следующем SCCRP или SCCCN, соответственно. Если ожидаемый отклик партнера не соответствует полученному, установление туннеля должно быть запрещено.

При участии в аутентификации туннеля LAC и LNS должны обладать общим секретным кодом. Это тот же секретный код, который использовался для AVP-сокрытия.

Установление сессии

После успешного установления управляющего соединения, могут формироваться индивидуальные сессии. Каждая сессия соответствует одному PPP информационному потоку между LAC и LNS. В отличие от установления управляющего соединения, установление сессии является асимметричным в отношении LAC и LNS. LAC запрашивает LNS доступ к сессии для входных запросов, а LNS запрашивает LAC запустить сессию для работы с исходящими запросами.



Рис.4. Схема взаимодействия по протоколу L2TP

Подобно протоколам PPTP и L2F, протокол L2TP предусматривает 3 этапа формирования защищенного виртуального канала:

Установление соединения с сервером удаленного доступа локальной сети.

Аутентификация пользователя.

Конфигурирование криптозащищенного туннеля.

Для установления соединения с сервером удаленного доступа локальной сети, в качестве которого выступает сетевой сервер L2TP, удаленный пользователь связывается по протоколу PPP с концентратором доступа L2TP, функционирующим на сервере провайдера Internet или другой публичной сети. На данном этапе концентратор доступа L2TP может выполнить аутентификацию пользователя от имени провайдера. Далее по имени пользователя концентратор доступа провайдера определяет IP-адрес сетевого сервера L2TP, принадлежащего требуемой локальной сети. Между концентратором доступа провайдера и сервером L2TP локальной сети устанавливается сессия по протоколу L2TP, называемая сессией L2TP.

После установки сессии L2TP происходит процесс аутентификации пользователя на сервере L2TP локальной сети. Для этого может использоваться любой из стандартных алгоритмов аутентификации, например, алгоритм CHAP. Как и в протоколах PPTP и L2F, в спецификации L2TP отсутствуют описания методов аутентификации.

В случае успешной аутентификации пользователя между концентратором доступа провайдера и сервером L2TP локальной сети создается криптозащищенный туннель. С помощью управляющих сообщений осуществляется настройка различных параметров туннеля. В одном туннеле могут мультиплексироваться несколько сессий L2TP. Сам протокол L2TP не специфицирует конкретные методы криптозащиты и предусматривает возможность использования различных стандартов шифрования. Однако если туннель формируется в IP-сетях, то криптозащита должна выполняться в соответствии с протоколом IPSec. В этом случае пакеты L2TP инкапсулируются в UDP-пакеты, которые передаются между концентратором доступа провайдера и сервером L2TP локальной сети через IPSec-туннель. Для этого задействуется UDP-порт 1701.

Несмотря на свои достоинства, протокол L2TP не устраняет всех недостатков туннельной передачи данных на канальном уровне. В частности, необходима поддержка L2TP провайдерами. Протокол L2TP ограничивает весь трафик рамками выбранного туннеля и лишает пользователей доступа к другим частям Internet. Для текущей (четвертой) версии протокола IP не предусматривается создание криптозащищенного туннеля между конечными точками информационного взаимодействия. Кроме того, предложенная спецификация обеспечивает стандартное шифрование только в IP-сетях при использовании протокола IPSec, который пока не получил достаточно широкого распространения. А это может привести к проблемам совместимости, так как каждый производитель будет использовать в продуктах под L2TP собственные технологии криптозащиты.



Практическая работа № 6. Протокол SSL

Для обеспечения безопасного доступа к WEB-серверам разработан протокол SSL. Этот протокол является доминирующим для шифрования обмена между клиентом и сервером. Протокол SSL имеет два уровня: протокол записей (SSL Record Protocol) и протокол диалога (SSL Handshake Protocol). Последний позволяет клиенту и серверу идентифицировать друг друга и согласовать использование определенного алгоритма шифрования и обменяться ключами.

Потокол SSL реализует следующие функции:

· Конфиденциальность соединения. После предварительного диалога определяется секретный ключ, который используется для симметричной криптографии (например, DES или rc4)

· Партнеры идентифицируют друг друга с помощью асимметричных криптографических методов (например, RSA или DSS)

...