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

4.2. Пакеты Success и Failure

Пакет Success передается идентифицирующей стороной партнеру после завершения метода идентификации EAP (тип 4 или выше) для индикации успешно завершенной идентификации партнера. Идентифицирующая сторона должна передать пакет EAP с Code = 3 (Success). Если партнера идентифицировать не удается (неприемлемые отклики на один или множество запросов), после неудачного завершения метода EAP реализация должна передать пакет EAP с кодом 4 (Failure). Идентифицирующая сторона может ввести множество запросов до передачи отклика Failure, чтобы предотвратить влияние ошибок (опечаток) пользователя. В пакеты Success и Failure недопустимо включать дополнительные данные.

Идентифицирующей стороне недопустимо передавать пакет Failure, если спецификация данного метода не позволяет явно заканчивать работу метода в этой точке. Реализация EAP на идентифицируемой стороне, получившая пакет Success или Failure, передача которого не назрешена явно, должна отбросить этот пакет без уведомления. По умолчанию идентифицируемая сторона EAP должна отбрасывать без уведомления «пьяные» пакеты Success (пакеты Success, переданные сразу после соединения). Это предотвращает для некорректно работающих реализаций идентифицирующей стороны возможность обойти взаимную идентификацию за счет передачи пакета Success до завершения транзакции метода EAP.

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

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

Идентифицируемая сторона после неудачного завершения метода идентификации (индикация отказа от идентифицирующей стороны или нежелание партнера продолжать транзакцию — возможно после передачи индикации негативного результата) должна прервать транзакцию и передать индикацию отказа на нижележащий уровень. Идентифицируемая сторона должна отбрасывать без уведомления пакеты Success и может отбрасывать без уведомления пакеты Failure. В результате потеря пакета Failure не будет приводить к тайм-ауту.

Идентифицируемая сторона после обмена индикаторами успешного завершения с обеих сторон, должна без уведомления отбрасывать пакеты Failure. Если пакет EAP Success не был получен, идентифицируемая сторона может предположить потерю пакета.

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

Если партнер сталкивается с отказом при попытке идентифицировать идентифицирующую сторону, последняя должна передать пакет Failure; недопустимо в таких случаях предоставлять доступ, передавая пакет Success. Однако идентифицирующая сторона может опускать идентификацию партнера в случаях предоставления ограниченного доступа (например, гостевого). В таком случае идентифицирующая сторона должна передать пакет Success.

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

Ниже показан формат пакетов Success и Failure. Поля передаются, начиная с лева на право.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Code
  • 3 для Success
  • 4 для Failure
  • Identifier
  • Поле Identifier имеет размер 1 октет и служит для сопоставления с откликами. Значение поля Identifier должно соответствовать значению идентификатора в пакете Response, на который передается ответ.
  • Length
  • 4
2007 - 2017 © Русские переводы RFC, IETF, ISOC.