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

2.2. Модель мультиплексирования EAP

Концептуально реализация EAP состоит из перечисленных ниже компонент.

  • Нижележащий уровень отвечает за передачу кадров EAP между идентифицирующей стороной и ее партнером. EAP работает на основе множества протоколов, включая PPP, проводные ЛВС IEEE 802 [IEEE-802.1X], беспроводные ЛВС IEEE 802.11 [IEEE-802.11], UDP (L2TP [RFC2661] и IKEv2 [IKEv2]) и TCP [PIC]. Поведение протоколов нижележащего уровня рассматривается в разделе 3.
  • Уровень EAP получает и передает пакеты EAP через нижележащий уровень, обеспечивает детектирование дубликатов и повторную передачу, а также доставляет и принимает сообщения EAP между уровнями идентифицирующей и идентифицируемой сторон EAP.
  • Уровни идентифицирующей и идентифицируемой сторон EAP. На основе поля Code уровень EAP демультиплексирует пакеты EAP на уровени идентифицирующей и идентифицируемой сторон EAP. Обычно реализация EAP на данном хосте будет поддерживать функциональность идентифицируемой или идентифицирующей стороны, но возможно и совмещение этих функций. В последнем случае в реализации EAP присутствуют уровни идентифицирующей и идентифицируемой сторон.
  • Уровень методов EAP реализует алгоритмы идентифкации, принимает и передает сообщения EAP через уровни идентифицирующей и идентифицируемой сторон EAP. Поскольку сам протокол не обеспечивает поддержки фрагментации, эта задача возлагается на методы EAP, как описано в разделе 5.

Рисунок 1 иллюстрирует модель мультиплексирования EAP. Отметим, что реализация не обязана строго следовать этой модели — важно, чтобы поведение «в проводе» соответствовало модели.

+-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+
|           |           |  |           |           |
| EAP method| EAP method|  | EAP method| EAP method|
| Type = X  | Type = Y  |  | Type = X  | Type = Y  |
|       V   |           |  |       ^   |           |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
|       !               |  |       !               |
|  EAP  ! Peer layer    |  |  EAP  ! Auth. layer   |
|       !               |  |       !               |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
|       !               |  |       !               |
|  EAP  ! layer         |  |  EAP  ! layer         |
|       !               |  |       !               |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
|       !               |  |       !               |
| Lower ! layer         |  | Lower ! layer         |
|       !               |  |       !               |
+-+-+-+-!-+-+-+-+-+-+-+-+  +-+-+-+-!-+-+-+-+-+-+-+-+
        !                          !
        !   Peer                   ! Authenticator
        +------------>-------------+

Рисунок 1: Модель мультиплексирования EAP

В EAP поле Code используется подобно номеру протокола в IP. Предполагается, что уровень EAP демультиплексирует входящие пакеты EAP по значению поля Code. Принятые пакеты EAP с кодами 1 (Request), 3 (Success) и 4 (Failure) доставляются уровнем EAP на уровень партнера EAP, если тот реализован. Пакеты EAP с кодом 2 (Response) доставляются уровню идентифицирующей стороны EAP, если он реализован.

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

Поскольку для методов идентификации EAP может оказаться желательным доступ к Identity, реализациям следует делать запросы и отклики Identity доступными для методов идентификации (типа 4 и выше), а не только методу Identity. Тип Identity рассматривается в параграфе 5.1.

Отклик Notification импользуется только в качестве подтверждения партнером запроса Notification, но не подтверждает его обработку или вывод для пользователя. Не следует предполагать, что содержимое запросов и откликов Notification доступно другим методам. Тип Notification рассмотрен в параграфе 5.2.

Методы Nak (тип 3) и Expanded Nak (тип 254) используются для согласования метода. Партнеры отыечают на начальный запрос EAP для неприемлемого типа откликом Nak (тип 3) или Expanded Nak (тип 254). Не следует предполагать, что содержимое откликов Nak доступно другим методам. Типы Nak рассмотрены в параграфе 5.3.

Пакеты EAP с кодами Success и Failure не включают поля Type и не доставляются методам EAP. Коды Success и Failure рассматриваются в параграфе 4.2.

С учетом сказанного здесь сообщения Success, Failure, отклики Nak Response, запросы и отклики Notification недопустимо использовать для передачи данных, адресованных методам EAP.

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