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

2.3. Проходной режим

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

Хост, получивший пакет EAP может выполнить по отношению к пакету только одну из трех операций — обработать, отбросить или переслать пакет. Решение о пересылке обычно принимается по результатам проверки полей Code, Identifier и Length. Работающая в проходном режиме реализация должна быть способна пересылать пакеты, полученные от партнера с кодом 2 (Response), внутреннему серверу идентификации. Одна также должна быть способна принимать пакеты EAP от внутреннего сервера и пересылать партнеру пакеты EAP с кодами 1 (Request), 3 (Success) и 4 (Failure).

Если идентифицирующая сторона не поддерживает локально один или несколько методов идентификации, способных идентифицировать партнера, поля заголовка уровня методов EAP (Type, Type-Data) не проверяются в процессе принятия решения о пересылке. Когда идентифицирующая сторона поддерживает локальные методы идентификации, она может проверять поле Type, чтобы определеить обрабатывать или пересылать пакет. Соответствующие спецификации реализации проходного режима должны по умолчанию пересылать пакеты EAP любого типа.

Пакеты EAP с кодами 1 (Request), 3 (Success) и 4 (Failure) демультиплексируются уровнем EAP и доставляются уровню партнера. Следовательно, если хост не реализует уровень партнера EAP, эти пакеты отбрасываются без уведомления. Аналогично, пакеты EAP с кодом 2 (Response) демультиплексируются уровнем EAP и доставляются уровню идентифицирующей стороны. Если хост не реализует уровень идентифицирующей стороны EAP, пакеты отбрасываются без уведомления. Поведение идентифицируемого узла в проходном режиме не рассматривается в спецификации и не поддерживается протоколами AAA типа RADIUS [RFC3579] и Diameter [DIAM-EAP].

Рисунок 2 иллюстрирует модель пересылки.

     Peer         Pass-through Authenticator   Authentication
                                                   Server

+-+-+-+-+-+-+                                   +-+-+-+-+-+-+
|           |                                   |           |
|EAP method |                                   |EAP method |
|     V     |                                   |     ^     |
+-+-+-!-+-+-+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+   +-+-+-!-+-+-+
|     !     |   |EAP  |  EAP  |             |   |     !     |
|     !     |   |Peer |  Auth.| EAP Auth.   |   |     !     |
|EAP  ! peer|   |     | +-----------+       |   |EAP  !Auth.|
|     !     |   |     | !     |     !       |   |     !     |
+-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
|     !     |   |       !     |     !       |   |     !     |
|EAP  !layer|   |   EAP !layer| EAP !layer  |   |EAP  !layer|
|     !     |   |       !     |     !       |   |     !     |
+-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
|     !     |   |       !     |     !       |   |     !     |
|Lower!layer|   |  Lower!layer| AAA ! /IP   |   | AAA ! /IP |
|     !     |   |       !     |     !       |   |     !     |
+-+-+-!-+-+-+   +-+-+-+-!-+-+-+-+-+-!-+-+-+-+   +-+-+-!-+-+-+
      !                 !           !                 !
      !                 !           !                 !
      +-------->--------+           +--------->-------+

Рисунок 2: Идентифицирующая сторона в проходном режиме

Для сессий, где идентифицирующая сторона работает в прозрачном режиме, результат идентификации должен определяться только на основе индикации Accept/Reject, переданной внутренним сервером идентификации; недопустимо определять результат по содержимому пакета EAP, переданного с индикацией Accept/Reject, или отсутствию такой индикации в инкапсулированном пакете EAP.

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