RFC: 3748
Оригинал: Extensible Authentication Protocol (EAP)
Предыдущие версии: RFC 2284
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Николай Малых

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

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

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

Защищенная индикация результатов устраняет некоторые уязвимости к атакам на службы с использованием обманных пакетов Success и Failure. Обычно методы EAP могут обеспечивать защищенную индикацию результатов лишь в некотрых случаях. Например, ошибка может произойти до создания ключа, поэтому такую индикацию защитить не удастся. Возможны случаи, когда индикация результатов не может поддерживаться в обоих направлениях или синхронизация возможна не во всех режимах работы.

Например, в EAP-TLS [RFC2716] при согласовании идентификации клиента сервер идентифицирует партнера, но не получает защищенной индикации от партнера в части идентификации тем сервера. Напротив, партнер идентифицирует сервер и знает, что сервер идентифицировал его. При согласовании восстановления сессии партнер идентифицирует сервер, но не получает защищенной индикации того, что сервер идентифицировал его. В этом режиме сервер идентифицирует партнера и знает, что тот идентифицировал его.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.