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

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

5.3. Nak

5.3.1. Обычный тип Nak

Традиционный тип Nak относится только к откликам. Этот тип устанавливается в откликах на запросы, когда желаемый тип идентификации недоступен. Типы идентификации могут иметь значение 4 и выше. Пакет Response содержит значение одного или нескольких типов идентификации, желаемых партнером. Тип 0 используется для индикации отсутствия предлагаемых типов идентификации, поэтому идентифицирующей стороне не следует передавать другой запрос после получения отклика Nak, содержащего нулевое значение.

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

  • Code
  • 2 для Response.
  • Identifier
  • Поле Identifier имеет размер 1 октет и служит для сопоставления откликов с запросами. Значение поля Identifier в традиционном отклике Nak должно соответствовать значению Identifier в пакете Request, на который передается отклик.
  • Length
  • <=6
  • Type
  • 3
  • Type-Data
  • Когда идентифицируемая сторона получает запрос для неподходящего типа идентификации (4-253, 255) или запрос для типа 254 при отсутствии поддержки расширенных типов, должен передаваться пакет Nak Response (тип 3). Поле Type-Data отклика Nak (тип 3) должно содержать один или множество октетов (по одному октету на тип), показывающих желаемые типы идентификации, или 0 для индикации отсутствия предложений. Партнер, поддерживающий расширенные типы при получении запроса для неподходящего типа идентификации (4-253, 255), может включить в отклик Nak (тип 3) значение 254 для индикации желания использовать расширенный тип. Если идентифицирующая сторона может принять это предложение, она будет отвечать на него сообщением Expanded Type Request (тип 254).

Параметры защиты (см. параграф 7.2) показаны в таблице.

Механизм идентификации Нет
Согласование криптографического набора Нет
Взаимная идентификация Нет
Защита целостности Нет
Защита от повторов Нет
Конфиденциальность Нет
Создание ключей Нет
Стойкость ключей -
Устойчивость к атакам по словарю -
Быстрый повтор соединения Нет
Криптографическая привязка -
Независимость сессий -
Фрагментация Нет
Связывание каналов Нет

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

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