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

5.1. Identity

Тип Identity используется для запроса идентификационной информации для партнера. В общем случае идентифицирующая сторона может ввести запрос этого типа в качестве стартового. В тех случаях, когда предполагается взаимодействие с пользователем на стороне партнера, может включаться дополнительное отображаемое сообщение. В ответ на запрос типа 1 (Identity) следует передавать отклик типа 1 (Identity).

Некоторые реализации EAP включают различные опции в запрос типа Identity после NUL-символа. По умолчанию реализации EAP не следует предполагать, что запрос или отклик типа Identity может быть больше 1020 октетов.

Рекомендуется использовать отклики Identity прежде всего в целях маршрутизации и выбора используемого метода EAP. Методам EAP следует включать механизм получения идентификационной информации, чтобы не возникало необходимости опираться при проверке тождественности на отклик Identity. Запросы и отклики Identity передаются в незашифрованном виде, поэтому атакующий может увидеть идентификационные данные и даже изменить их. Для предотвращения такой угрозы предпочтительно включать в идентификационный обмен метод EAP, который поддерживает идентификацию на уровне пакетов, а также обеспечивает защиту целостности, конфиденциальность и предотвращение повторного использования пакетов. Отклик Identity может оказаться неподходящим ответом для такого метода — он может быть усеченным или затуманенным для сохранения тайны, а также «декорированным» для маршрутизации. Когда партнер настроен на восприятие только методов идентификации, поддерживающих защищенные обмен идентификационными данными, этот партнер может предоставлять сокращенный отклик Identity (например без своего имени в NAI [RFC2486]). Дополнительное рассмотрение этого вопроса содержится в параграфе 7.3.

Примечание для разработчиков. Партнер может получать в результате ввода данных пользователем. Идентифицирующей стороне рекомендуется повторять Identity Request в случаях получения некорректных идентификационных данных или отказа при идентификации, поскольку пользователи могут ошибаться при вводе. Предлагается повторять Identity Request не менее 3 раз, прежде чем прервать идентификацию. Для индикации некорректной попытки перед повтором Identity Request может передаваться Notification Request. Возможно также индицировать отказ в сообщении нового запроса Identity.

  • Type
  • 1
  • Type-Data
  • Это поле может содержать отображаемое сообщение, представленное символами ISO 10646 с кодировкой UTF-8 [RFC2279]. Если Request содержит null-символ, выводиться будет только часть этого поля до символа null. Если значение Identity неизвестно, в отклик Identity следует включать поле нулевого размера. В откликах Identity недопустимо завершать поле null-символом. В любом случае размер поля Type-Data определяется из значения поля Length в пакете Request/Response.

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

Механизм идентификацииНет
Согласование криптографического набораНет
Взаимная идентификацияНет
Защита целостностиНет
Защита от повторовНет
КонфиденциальностьНет
Создание ключейНет
Стойкость ключей-
Устойчивость к атакам по словарю-
Быстрый повтор соединенияНет
Криптографическая привязка-
Независимость сессий-
ФрагментацияНет
Связывание каналовНет
2007 - 2017 © Русские переводы RFC, IETF, ISOC.