Совместное использование протоколов L2TP и IPSec

Во время переговоров IPSec IKE должен быть выбран метод аутентификации. В дополнение к IKE-аутентификации L2TP-протокол использует методы РРР-аутентификации. Обсудим проблемы, связанные с аутентификацией.

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

В IPSec после того, как в IKE выполнена аутентификация и вычислены общие ключи, эти ключи используются для обеспечения аутентификации на уровне пакетов, целостности и защиты от replay-атак. И как результат идентификация проверяется при получении каждого пакета.

Другое различие состоит в том, что идентификация, предоставляемая РРР, является идентификацией на уровне пользователя, а идентификация, предоставляемая IKE, является идентификацией на уровне компьютера.

Так как только идентификация компьютера проверяется на уровне пакетов, то не существует способа проверить, что только аутентифицированный РРР-пользователь использует туннель. ПО IPSec, обеспечивающее аутентификацию на уровне компьютера, обычно не имеет возможности сегрегации трафика на уровне различных пользователей данного компьютера. Как следствие, если используется аутентификация на уровне компьютера, то после открытия L2TP/IPSec туннеля любой пользователь в многопользовательской среде обычно имеет возможность посылать трафик по туннелю.

Если ПО IPSec поддерживает аутентификацию на уровне пользователя, то эту проблему можно решить. В этом случае идентификация пользователя, вставленная в IKE, будет проверяться для каждого пакета. Для того, чтобы обеспечить сегрегацию трафика между пользователями, если используется аутентификация на уровне пользователя, клиент должен гарантировать, что по L2TP-туннелю посылается только трафик определенного пользователя.

Если в IKE выбрана аутентификация с помощью сертификатов Х.509, то считается, что в LNS для запроса сертификата клиента в IKE будет использоваться специальное содержимое CERP. В LNS может присутствовать несколько CERP, если несколько сертификационных центров являются доверенными, т.е. сконфигурированы в политике аутентификации IPSec IKE.

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

LNS может динамически назначать порты источника и получателя только в том случае, если об этом договорились в IKE.

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

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

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

Использование аутентификации по общему секрету в Main Mode IKE уязвимо для атак "man-in-the-middle", когда этот секрет используется для получения удаленного доступа. В Main Mode использование SKEYID_e необходимо до получения идентификации. Следовательно, выбор разделяемого ключа может быть сделан только на основании информации, содержащейся в IP-заголовке. Однако в случае удаленного доступа обычно IP-адрес назначается динамически, поэтому часто бывает невозможно определить требуемый разделяемый ключ, основываясь только на IP-адресе.

Таким образом, когда в сценариях удаленного доступа используется аутентификация по общему секрету, один и тот же секрет используется группой пользователей. В такой ситуации невозможна ни идентификация сервера, ни идентификация клиента в I фазе IKE; возможно только доказать, что оба участника являются членами группы, которые знают разделя-емый секрет. Это допускает ситуацию, когда кто-либо может получить доступ к разделяемому секрету группы и выполнить атаку "man-in-the-middle".

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

В результате этого, если используется Main Mode с разделяемыми секретами и если РРР не выполняет взаимную аутентификацию, то сервер не аутентифицирован. Это дает возможность поддельному серверу получить доступ к групповому разделяемому секрету для успешной подделки под LNS и провести словарную атаку на такие наследуемые методы аутентификации как СНАР. Такая атака может потенциально компрометировать достаточно большое количество паролей. Подобная уязвимость существует в некоторых реализациях туннельного режима IPSec.

Чтобы избежать подобной проблемы, производители L2TP/IPSec не должны использовать групповой разделяемый секрет для IKE-аутентификации в LNS. Разделяемый ключ IKE должен быть защищен аналогично тому, как защищены пароли пользователей, используемые в L2TP.

Когда L2TP защищен с помощью IPSec, доступны сервисы безопасности как РРР, так и IPSec. Какие сервисы будут использоваться, зависит от того, является ли туннель обязательным или добровольным. Проанализируем сценарии обязательного и добровольного туннелирования.

Будем предполагать, что как клиенты, так и сервера L2TP могут устанавливать и получать свойства IPSec SA, а также влиять на сервисы безопасности IPSec, о которых ведутся переговоры. Более того, будем предполагать, что клиенты и серверы L2TP могут влиять на процесс переговоров относительно РРР-шифрования и сжатия.

Обязательное туннелирование

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

Так как LNS может узнать, имеется ли конфиденциальность, целостность, аутентификация и защита от replay-атак между ним и LAC, он может использовать эти знания для модификации своего поведения при переговорах РРР ЕСР и ССР. Предположим, что политика конфиденциальности LNS может быть описана одним из следующих терминов: "Требуется шифрование", "Допустимо шифрование" и "Запрещено шифрование". Если сервисы конфиденциальности IPSec имеют место, то LNS устанавливает политику "Запрещено шифрование". Это не тоже самое, что просто отключить РРР-шифрование и сжатие, так как в этом случае окончательное решение зависит от политики клиента.

Так как клиент не знает о сервисах безопасности, используемых между LAC и LNS, и так как для соединения между клиентом и LAC также могут требоваться сервисы безопасности, клиент обычно использует РРР-шифрование между ним и LNS.

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

В результате этого LAC может вести переговоры с LNS для ESP с нулевым шифрованием, а LNS может обеспечивать защиту от replay-атак. Это гарантирует, что сервисы конфиденциальности и сжатия не будут дублироваться между LAC и LNS.

Добровольное туннелирование

В случае добровольного туннелирования клиент посылает L2TP-пакеты к NАS, который затем их маршрутизирует к LNS. В случае dial-up эти L2TP-пакеты будет инкапсулированы в IP и РРР. В этом случае клиент знает сервисы безопасности между ним и LNS. Он также знает о сервисах РРР-шифрования и сжатия, о которых были переговоры между ним и NAS.

Так как LNS имеет возможность узнать, используется ли конфиденциальность, аутентификация, проверка целостности и защита от replay-атак между ним и клиентом, он может использовать эту информацию для модификации переговоров РРР ЕСР и ССР. Если установлена IPSec-конфиденциальность, то LNS может считать, что директива "Требуется шифрование" установлена, и не обязательно использовать РРР-шифрование и сжатие. Обычно LNS не требует, чтобы РРР-шифрование и сжатие были выключены, предоставляя решение об этом принимать клиенту.