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

RFC 3748, Страница 15 из 46

4.1. Запросы и отклики

Пакеты Request (запрос, код 1) передаются партнеру идентифицирующей стороной. Каждый пакет Request имеет поле Type, которое показывает тип запрашиваемой информации. Дополнительные пакеты Request должны передаваться, пока не будет получен корректный отклик, не завершится отсчет числа попыток или нижележащий уровень не сообщит об отказе.

Повторные запросы должны передаваться с тем же значением поля Identifier, чтобы их можно было отличить от новых запросов. Содержимое поля данных зависит от типа запроса. Партнер должен передавать пакет Response в ответ на корректный запрос. Отклики должны передаваться только в ответ на корректные пакеты Request и никогда не должны повторяться по таймеру.

Если партнер получает корректный дубликат запроса, на который уже передан отклик, он должен повторить передачу исходного пакета Response без обработки полученного дубликата. Запросы должны обрабатываться в порядке их получения, обработка предыдущего запроса должна быть завершена до начала работы с новым пакетом Request.

Ниже приводится описание полей пакетов Request и Response. Поля передаются, с лева на право.

 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |  Type-Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  • Code
  • 1 для Request
  • 2 для Response
  • Identifier
  • Поле Identifier имеет размер 1 октет. Значения идентификатора в передаваемых повторно (по атйм-ауту в ожиданни отклика) пакетах запросов должны совпадать со значением поля в исходном пакете Request. В новых (не повторных) запросах значение поля Identifier должно меняться.

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

    Для того, чтобы не путались новые запросы с повторами предыдущих, выбираемые для каждого нового пакета Request значения поля Identifier должны отличаться только от идентификатора в исходном запросе — уникальности идентификаторов для всех запросов транзакции не требуется. Одним из путей решения этой задачи является увеличение значения поля Identifier на 1 в каждом новом запросе. Рекомендуется для превого запроса выбирать значение идентификатора случайным образом, а не начинать отсчет с нуля, поскольку такое решение несколько затруднит организацию атак.

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

    Примечание для разработчиков. Идентифицирующая сторона несет ответственность за повторную передачу пакетов Request. Если сообщение Request получено из некого источника (например, от внутреннего сервера идентификации), идентифицирующая сторона должна сохранить копию такого запроса на случай возможного повтора передачи. Партнер отвечает за детектирование и обслуживание дубликатов запросов до начала какой-либо их обработки, включая передачу третьей стороне. Идентифицирующая сторона отвечает также за отбрасывание сообщений Response с несоответствующим значением поля Identifier до какой-либо их обработки, включая пересылку внутреннему идентификационному серверу для проверки. Поскольку идентифицирующая сторона может повторить передачу до получения от партнера отклика, она может получить множество пакетов Response с одним идентификатором. Пока идентифицирующей стороной не будет принят новый запрос, значение поля Identifier не изменяется, поэтому идентифицирующая сторона пересылает отклики внутреннему серверу идентификации по одному.

  • Length
  • Двухоктетное поле Length показывает размер пакета EAP с учетом полей Code, Identifier, Length, Type и Type-Data. Октеты, выходящие за пределы указанного размера, следует трактовать, как заполнение канального уровня — на приеме эти данные должны игнорироваться. Сообщения, в которых значение поля Length превышает размер полученного пакета, должны отбрасываться без уведомления.
  • Type
  • Поле Type имеет размер 1 октет и показывает тип запроса или отклика. В каждом пакете EAP Request или Response должно быть указано одно значение Type. Исходные спецификации типов описаны в разделе 5 данного документа.

    Поле Type в отклике должно соответствовать полу типа в запросе или обычному/расширенному Nak (см. параграф 5.3), показывающему неприемлемость типа запроса для партнера. Партнеру недопустимо слать пакет Nak (обычный или расширенный) в ответ на запрос после того, как был передан исходный отклик без Nak. Сервер EAP, получивший пакет Response, который не удовлетворяет перечисленным здесь требованиям, должен отбросить его.

  • Type-Data
  • Поле Type-Data зависит от типа запроса и отклика.

Страница 15 из 46

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