Кратко

  • RFC 5421 описывает EAP-FAST-GTC, который использует тип 6, ранее назначенный EAP-GTC, для другого внутреннего обмена в туннеле.
  • Запреты на использование внутри и вне туннеля вместе с предупреждением IESG делают контекст EAP-FAST частью идентичности метода. Это вывод об устройстве реализации, а не свидетельство измеренного сбоя.

Одного октета недостаточно

Поле Type в EAP занимает один октет, но по нему выбирается способ обработки. RFC 3748 говорит, что поле указывает метод, а уровни EAP направляют пакеты соответствующему обработчику по значению Type — примерно так же, как транспортный порт задаёт назначение. Поэтому Type 6 на первый взгляд означает Generic Token Card.

RFC 5421 добавляет условие, которого не видно в одном байте. Информационный меморандум 2009 года описывает EAP-FAST-GTC — внутренний метод для простого обмена паролем. Среди его целей названы устаревшие базы паролей, смена пароля и одноразовые пароли. По историческим причинам метод использует код, изначально назначенный EAP-GTC. В действующем реестре IANA тип 6 по-прежнему обозначен как «Generic Token Card»; RFC 5421 не создавал второе глобальное назначение.

Различие задают рамка и формат данных. EAP-FAST устанавливает TLS-туннель, а во внутренней фазе пакеты EAP передаются в TLV-объектах EAP Payload. RFC 5421 отмечает, что формат EAP-FAST-GTC специфичен для туннеля и может не совпадать с обычным EAP-GTC вне него. Поэтому действуют два встречных ограничения: EAP-FAST-GTC НЕЛЬЗЯ использовать вне туннеля EAP-FAST, а EAP-GTC НЕЛЬЗЯ использовать внутри.

Эти правила определяют, что означает Type 6 в каждом из контекстов. Если диспетчер сохраняет только значение Type и теряет сведения о том, пришёл ли пакет из внешнего обмена или из внутренней фазы EAP-FAST, он отбрасывает данные, нужные протоколу для различения методов. Это следствие для проектирования реализации, а не утверждение о том, что существующие системы уже ошибались.

Предупреждение о совместимости сформулировано прямо

В примечании IESG к RFC 5421 сказано, что повторное использование назначенных кодов EAP несовместимо с согласованием методов по RFC 3748. У EAP-GTC нет собственного согласования версии метода, поэтому внутри туннеля предполагается, что Type 6 обозначает EAP-FAST-GTC. Примечание предупреждает о возможных проблемах, если реализация должна также поддерживать EAP-GTC другого производителя; обработка одного кода внутри и вне туннеля требует специальных случаев. Уникальные Type-коды устранили бы эту сложность. Для будущих туннельных методов назначенные типы нельзя повторно использовать с другим значением.

Область вывода нужно сохранить. RFC не утверждает, что каждое согласование завершается ошибкой, не отзывает Type 6 и не выявляет дефект конкретного нынешнего продукта. Документ фиксирует стоимость совместимости, возникающую из-за контекстного значения кода. Реестр задаёт глобальное название, правила туннеля ограничивают внутреннее применение, а примечание IESG объясняет напряжение между ними.

Принцип первичности работающего кода здесь полезен как редакционная оптика: запись в реестре не описывает всю систему. Важен и код, который принимает пакет, определяет его уровень и выбирает метод. Note 65 Хэна Лу помогает сформулировать эту перспективу, но не подтверждает требования EAP или поведение поставщиков.

Защита учётных данных — отдельная граница

RFC 5421 также указывает, что EAP-FAST-GTC передаёт парольные сведения в виде открытых строк внутри зашифрованного TLS-туннеля. Узел должен аутентифицировать сервер до раскрытия учётных данных. В режиме Server-Unauthenticated Provisioning, где сервер не аутентифицируется, использовать EAP-FAST-GTC НЕЛЬЗЯ. Это отдельное важное условие безопасности: шифрование канала само по себе не решает задачу выбора метода, а выбор правильного метода не доказывает аутентификацию сервера.

Операционный вопрос находится на стыке: где именно система решает, что Type 6 означает обычный EAP-GTC или EAP-FAST-GTC? Решение должно учитывать и Type, и фазу туннеля, а встречные запреты должны исполняться. Тесты могут проверить GTC снаружи и FAST-GTC внутри, а затем убедиться, что оба метода отклоняются в противоположном контексте. Это предлагаемый способ проверки, а не новое требование RFC.

RFC 5421 имеет статус Informational. Открытые источники не подтверждают нынешнюю распространённость, поведение поставщиков или реальные инциденты. Более точный вывод таков: если код метода повторно используется под туннелем, внешняя рамка становится операционным контекстом, который диспетчер не должен терять.

Источники