Протокол РРР

Протокол CHAP

Протокол аутентификации запрос-ответ Challenge-Handshake Authentication Protocol (CHAP) используется для реализации функций безопасности при установлении РРР-соединения. В протоколе CHAP применяется трехразовая проверка подлинности при регистрации клиента на хосте. В RFC 1994 описан алгоритм, реализуемый в протоколе CHAP. Формат пакета протокола CHAP представлен на рис. 8.6.

Рис. 8.6. Формат пакета протокола CHAP

Поле Код имеет в длину один октет и идентифицирует тип пакета CHAP. В табл. 8.4 представлены возможные значения поля Код.

Поле Идентификатор имеет в длину один октет. С помощью этого поля происходит идентификация пакета CHAP. Затем клиент и хост по этому идентификатору могут согласовывать свои запросы и ответы на них.

Поле Длина составляет два октета. Это поле используется для задания длины пакета CHAP. Длина пакета считается с учетом полей Код, Идентификатор, Длина и Данные.

Поле Данные может быть нулевой длины или несколько октетов в длину. В него включаются данные, которые заданы в поле Код пакета CHAP.

На рис. 8.7 показан протокол, подтверждающий установление соединения, который применяется в CHAP для проверки подлинности клиента. Подтверждение установления соединения в CHAP проходит в три фазы.

• Хост посылает пакет запроса CHAP-клиенту со случайным значением.
• Клиент отвечает пакетом ответа CHAP, в который включено значение, вычисленное с помощью наложения на значение вызова секретного ключа. Ключ выводится с помощью односторонней функции хеширования.
• Далее хост сверяет значение в ответе клиента, с полученным им самим таким же способом (наложение значения вызова на ключ). Если они совпадают, то хост высылает пакет "Success" (Успешная аутентификация), и сеанс РРР продолжается. В противном случае хост посылает клиенту пакет "Failure"(Отказ), сеанс РРР прекращается и формируется LCP-пакет типа Terminate-Request.

Рис. 8.7. Фазы подтверждения установления соединения в протоколе CHAP

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

Протокол PAP

В отличие от протокола CHAP, протокол установления подлинности пароля Password Authentication Protocol (PAP) не является столь изощренным. В этом протоколе используется простой механизм проверки подлинности пользователя с помощью userid/password. Идентификатор пользователя userid посылается в текстовом виде в формате ASCII. Пароль может шифроваться, а может передаваться и в текстовом виде. Это зависит от возможностей клиента.

После аутентификации клиента продолжается сеанс РРР. При этом в течение сеанса повторная аутентификация не производится. Если клиент не подтвердил свои полномочия соответствующим образом, то сеанс РРР может быть прекращен хостом РРР.

Метод проверки подлинности с помощью PAP легко реализуется, но имеет меньший уровень безопасности. Одна из причин его популярности у провайдеров услуг сети Internet заключается в том, что безопасность коммутируемых соединений не является определяющим фактором при организации подключения к сети Internet. Прослушивание телефонной линии с целью перехвата сеанса РРР довольно затруднительно, в отличие от перехвата пароля, который посылается по локальной сети Ethernet в текстовом виде. Таким образом, простота настройки PAP перевешивает возможную угрозу, связанную с низким уровнем его безопасности.

Фаза согласования сетевых протоколов

После установления соединения в фазе переговоров LCP могут организовываться отдельные сетевые сеансы. В протоколе РРР предусмотрена возможность одновременной передачи данных нескольких сетевых протоколов. Организация сеанса передачи для каждого сетевого протокола происходит в фазе согласования сетевых протоколов. Согласование параметров сетевых протоколов в сеансе РРР осуществляется с помощью протокола сетевых соединений Network Connection Protocol (NCP). Для работы сервера электронной почты на базе ОС Linux по РРР требуется лишь один протокол — IP. Протокол NCP используется для согласования параметров IP-соединения, и сеанс РРР называется протоколом управления IP или IPCP.

Протокол IPCP

Для поддержки сети IP через РРР обеими сторонами должен поддерживаться протокол управления IP. Протокол IPCP используется для согласования параметров протокола IP между двумя сторонами. Когда в кадре РРР содержится пакет IPCP, то в поле Протокол кадра РРР будет установлена величина 8021 (см. табл. 8.1).

Формат кадра IPCP идентичен формату кадра LCP (см. рис. 8.4). В поле Код пакета IPCP используются те же самые коды, что и в пакетах LCP, но распознаются только два из них — 1 и 7 (согласно табл. 8.2). Метод согласования параметров в IPCP полностью совпадает с процедурой ведения переговоров в LCP. Для согласования параметров клиент посылает на хост пакет типа Configure-Request. Если хост согласен с параметрами, предлагаемыми клиентом, он отвечает пакетом Configure-Ack, в противном случает он отвечает пакетом Configure-Nak.