Приложения A. Отличия от RFC 2284
В этом разделе перечислены основные различия между [RFC2284] и данным документом. Мелкие отличия, включая стили, грамматику, опечатки и редакторские правки не упомянуты в списке.
- Раздел, посвященный терминологии (параграф 1.2) был расширен, определены концепции и даны более точные определения.
- Введены и рассмотрены в документе концепции взаимной идентификации (Mutual Authentication), создания ключей (Key Derivation) и индикации результатов (Result Indications).
- В разделе 2 явно указано что в идентификационном обмене EAP может происходить множество обменов пакетами Request и Response. Возможности использования этого детально описаны в параграфе 2.1.
- В разделе 2 явно приведены некоторые требования к идентифицирующей стороне в проходном режиме.
- Добавлена модель мульиплексирования EAP (параграф 2.2) для иллюстрации типового применения EAP. Реализации не обязаны соответствовать этой модели, достаточно совместимого с моделью поведения.
- Описана работа EAP с различными протоколами нижележащего уровня в дополнение к протоколу PPP, для которого разрабатывался EAP.EAP.EAP.EAP. Добавлен раздел 3, посвященный поведению нижележащего уровня.
- При описании взаимодействия запросов и откликов EAP (параграф 4.1) более точно описано поведение при получении дубликатов запроса и отбрасывание пакетов без уведомления.
- В параграфе 4.2 разъяснено, что пакеты Success и Failure не должны содержать дополнительных данных и расширены примечания для разработчиков. Добавлен подпараграф с требованиями по обработке пакетов Success и Failure.
- В разделе 5 on описаны два новых типа EAP — Expanded (параграф 5.7), который используется для расширения пространства типов, и Experimental. В пространстве Expanded Type добавлен новый тип Expanded Nak (параграф 5.3.2). Приведены дополнительные пазъяснения для большинства существующих типов. Добавлены описания параметров защиты для методов идентификации.
- В параграфах 5, 5.1 и 5.2 добавлены требования к отображаемым полям по использованию символов ISO 10646 в кодировке UTF-8.
- В параграфе 5.1 сказано, что при наличии в поле Type-Data запроса Identity символа NUL отображается только часть сообщения до этого символа. RFC 2284 запрещает использование null-символов в поле Type-Data сообщений Identity. Это правило смягчает требования к запросам Identity и поле Type-Data в них может включать null-символы.
- В параграфе 5.5 добавлена поддержка откликов OTP Extended [RFC2243] в EAP OTP.
- Добавлен раздел «Согласование с IANA» (раздел 6) с правилами регистрации имен для EAP.
- Раздел «Вопросы безопасности» (раздел 7) был существенно расширен и включает в настоящем документе более полное описание возможных угроз и других вопросов безопасности.
- В параграф 7.5 был добавлен текст, описывающий специфическое поведение методов EAP в плане проверки целостности. При наличии возможности желательно рассчитывать специфическое для метода значение MIC с покрытием всего пакета EAP, включая заголовок уровня EAP (поля Code, Identifier, Length) и заголовок уровня метода EAP (поля Type, Type-Data).
- В параграфе 7.14 описаны риски, связанные с использованием открытых паролей в EAP.
- В параграф 7.15 добавлен текст, посвященный детектированию подставных NAS.
Адреса авторов
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052 USA
Phone: +1 425 706 6605
Fax: +1 425 936 6605
EMail: moc.tfosorcim@adranreb
Larry J. Blunk
Merit Network, Inc
4251 Plymouth Rd., Suite 2000
Ann Arbor, MI 48105-2785 USA
Phone: +1 734-647-9563
Fax: +1 734-647-3185
EMail: ude.tirem@bjl
John R. Vollbrecht
Vollbrecht Consulting LLC
9682 Alice Hill Drive
Dexter, MI 48130 USA
EMail: ude.hcimu@vrj
James Carlson
Sun Microsystems, Inc
1 Network Drive
Burlington, MA 01803-2757 USA
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: moc.nus@noslrac.d.semaj
Henrik Levkowetz
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28 SWEDEN
Phone: +46 708 32 16 08
EMail: moc.ztewokvel@kirneh