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

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

1.2. Терминология

Ниже определены часто используемые в этом документе термины.

  • Authenticator — идентифицирующая сторона
  • Инициирующая идентификацию EAP сторона соединения. Термин authenticator используется в стандарте [IEEE-802.1X] и в данном документе его трактовка совпадает с принятой в этом стандарте.
  • Peer — партнер
  • Сторона соединения, отвечающая на запрос идентификации. В стандарте [IEEE-802.1X] для обозначения этой стороны соединения используется термин Supplicant.
  • Supplicant — идентифицируемая сторона
  • Сторона соединения, отвечающая на запрос идентификации. Трактовка этого термина в данном документе совпадает с трактовкой в стандарте [IEEE-802.1X]. Кроме того, в этом документе для обозначения отвечающей на запрос идентификации стороны используется термин peer (партнер).
  • Backend authentication server — внутренний сервер идентификации
  • Внутренний сервер идентификации представляет собой объект, обеспечивающий услуги идентификации для идентифицирующей стороны. При использовании этого сервера он обычно выполняет методы EAP для идентифицирующей стороны. Такая же терминология применяется в стандарте [IEEE-802.1X].
  • AAA
  • Идентификация (Authentication), проверка полномочий (Authorization) и учет (Accounting). Протоколы AAA для работы с EAP включают RADIUS [RFC3579] и Diameter [DIAM-EAP]. В этом документе термины «сервер AAA» и «внутренний сервер идентификации» используются, как синонимы.
  • Displayable Message — отображаемое сообщение
  • Понятная человеку строка символов. Кодирование сообщений должно следовать форматц преобразований UTF-8 [RFC2279].
  • EAP server — сервер EAP
  • Объект, завершающий использование метода идентификации EAP с идентифицируемой стороной. При использовании внутреннего сервера идентификации сервер EAP является частью идентифицирующей стороны. При работе идентифицирующей стороны в проходном (pass-through) режиме сервер EAP размещается на внутреннем сервере идентификации.
  • Silently Discard — отбрасывание без уведомления
  • Отбрасывание пакета без дальнейшей обработки. Реализации следует обеспечивать возможность протоколирования таких событий с записью содержимого отбрасываемых пакетов и учитывать такие события в записях статистики.
  • Successful Authentication — успешная идентификация
  • В контексте этого документа успешная идентификация означает обмен сообщениями EAP, в результате которого идентифицирующая сторона принимает решение о предоставлнии доступа идентифицируемой стороне, а та принимает решение об использовании этого доступа. Решение идентифицирующей стороны обычно включает два аспекта — идентификацию и проверку полномочий; идентифицируемая сторона может принять идентификацию другой стороны, но отвергнуть ее доступ в соответствии с принятой политикой.
  • Message Integrity Check (MIC) — проверка целостности сообщения
  • Функция хэширования (в ключом), используемая для идентификации и защиты целостности данных. Обычно используется термин MAC, но в спецификациях IEEE 802 (и в данном документе используется акроним MIC во избежание путаницы с контролем доступа к среде — Medium Access Control.
  • Cryptographic Separation — криптографическое разделение
  • Два ключа (x и y) считаются «криптографически разделенными», если наличие всех сообщений, переданных с использованием протокола, не позволяет определить x по y или y по x без «взломов» криптографических значений. В частности, это определение позволяет противнику иметь информацию о всех nonce, переданных откпытым текстом, и предсказать значения всех используемых протоколом счетчиков. Криптографический взлом будет обычно требовать обращения необратимой (one-way) функции или предсказания выходного значения генератора псевдо-случайных чисел без знания секрета. Иными словами, если ключи разделены криптографически, не существует способа сокращения расчета x из y или y из x, и противник должен выполнить расчет, эквивалентный по объему поиску значения секретного ключа.
  • Master Session Key (MSK) — основной ключ сеанса
  • Ключевой материал, создаваемый сервером и идентифицируемой стороной EAP, который экспортируется методом EAP. MSK имеет размер не менее 64 октетов. В существующих реализациях сервер AAA, действующий в качестве сервера EAP, транспортирует MSK идентифицирующей стороне.
  • Extended Master Session Key (EMSK) — расширенный основной ключ сеанса
  • Дополнительный ключевой материал, создаваемый клиентом и сервером EAP, который экспортируется методом EAP. Размер EMSK составляет не менее 64 октетов. EMSK не используется совместно с идентифицирующей стороной или третьими сторонами. EMSK зарезервирован на будущее и в настоящее время не используется.
  • Result indications — индикация результата
  • Метод обеспечивает индикацию результата, если после передачи и получения последнего сообщения:
  • 1. Идентифицируемая сторона понимает, была ли она идентифицирована сервером и был ли сервер идентифицирован ею.
  • 2. Сервер понимает, идентифицировал ли он другую сторону и был ли идентифицирован ею.

В случаях, когда успешной идентификации достаточно для предоставления доступа стороны будут также знать о желании другой стороны предоставить доступ. Это бывает не всегда. Идентифицируемая сторона может отвергнуть доступ по причине отсутствия недостаточных полномочий (например, ограничение на число сессий) или по иным причинам. Поскольку обмен EAP осуществляется между идентифицируемой стороной и сервером, на решение о предоставлении доступа могут влиять и друге узлы (например, AAA-прокси). Более детальное обсуждение этого вопроса содержится в параграфе 7.16.

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

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