RFC: 4306
Оригинал: Internet Key Exchange (IKEv2) Protocol
Другие версии: RFC 2407, RFC 2408, RFC 2409, RFC 5996
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4306, Страница 56 из 62

3.16. Элемент EAP

Элемент Extensible Authentication Protocol (EAP) позволяет выполнять идентификацию IKE_SA с использованием протокола, определенного в RFC 3748 [EAP] и его последующих расширений. that protocol. Полный набор приемлемых значений выходит за пределы этой спецификации, однако краткий перечень значений из RFC 3748 включен в документ для использования в наиболее общих случаях.

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload  !C!  RESERVED   !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       EAP Message                             ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 24: Формат EAP

Идентификатор типа для элемента данных EAP Payload имеет значение 48.

                     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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Рисунок 25: Формат сообщения EAP
  • Code (1 октет) показывает, является это сообщение запросом (Request — 1), откликом (Response — 2), успешным завершением (Success — 3) или отказом (Failure — 4).

  • Identifier (1 октет) используется в PPP, чтобы отличить повторное использование сообщений от повторной передачи. Поскольку в IKE протокол EAP работает на базе протокола с гарантированной доставкой, использование идентификатора смысла не имеет. В откликах этот октет должен устанавливаться равным значению идентификатора в соответствующем запросе. В остальных сообщениях это поле может принимать любое значение.

  • Length (2 октета) показывает размер сообщения EAP и должно быть в 4 раза меньше значения поля Payload Length инкапсулирующего элемента.

  • Type (1 октет) присутствует только в сообщениях с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а поля Type и Type_Data должны отсутствовать. В запросах (1) поле Type показывает запрашиваемые данные, а в откликах (2) поле Type должно быть пустым или соответствовать типу запрошенных данных В RFC 3748 определены следующие типы:

    1. Identity — тождественность
    2. Notification — уведомление
    3. Nak (только отклики)
    4. MD5-Challenge
    5. One-Time Password (OTP) — однократный пароль
    6. Generic Token Card — маркерная карта базового типа
  • Type_Data (переменный размер) зависит от типа запроса и связанного с ним отклика. Дополнительная информация по методам EAP приведена в работе methods, see [EAP].

Поскольку IKE передает идентификацию инициатора в протокольном сообщении с номером 3, ответчику не следует передавать запросы EAP Identity. Инициатору следует, однако, отвечать на такие запросы при их получении.

Страница 56 из 62

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