Коммутация LAN : 802.1x

Реализации фрагментации EAP и поведение

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (19 декабря 2015) | Отзыв

Введение

Этот документ описывает, как понять и устранить неполадки сеансов Протокола EAP. Эти проблемы обсуждены:

  • Поведение серверов Аутентификации, авторизации и учета (AAA), когда они возвращают Серверный сертификат для Transport Layer Security расширяемого протокола аутентификации (EAP-TLS) сеанс
  • Поведение соискателей, когда они возвращают Сертификат клиента для сеанса EAP-TLS
  • Совместимость, когда используются и Собственный Соискатель Microsoft Windows и Менеджер доступа к сети (NAM) AnyConnect Cisco
  • Фрагментация в IP, RADIUS, и EAP-TLS и процессе повторной сборки, выполненном устройствами доступа к сети
  • Обрамленный Максимальный размер передаваемого блока данных RADIUS (MTU) атрибут
  • Поведение AAA-серверов, когда они выполняют фрагментацию пакетов EAP-TLS

Внесенный Михалом Гаркарзом, Дэвидом Беднэрчиком, и Войцехом Секотом, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Компания Cisco рекомендует предварительно ознакомиться со следующими предметами:

  • EAP и протоколы EAP-TLS
  • Конфигурация платформы Cisco Identity Services Engine (ISE)
  • Конфигурация интерфейса командой строки коммутаторов Cisco Catalyst

Необходимо иметь хорошее понимание EAP и EAP-TLS для понимания этой статьи.

Цепочка сертификатов, возвращенная сервером

AAA-сервер (Access Control Server (ACS) и ISE) всегда возвращает полную цепочку для пакета EAP-TLS с Приветствие сервера и Серверный сертификат:

Сертификат идентификации ISE (Общее имя (CN) =lise. пример. com), возвращен наряду с Центром сертификации (CA), который подписал CN=win2012, dc=example, dc=com. Поведение является тем же и для ACS и для ISE.

Цепочка сертификатов, возвращенная соискателем

Собственный соискатель Microsoft Windows

Microsoft Windows, который настроили 7 Собственных соискателей для использования EAP-TLS, с или без "Выбора простого сертификата", не передает полную цепочку сертификата клиента. Это поведение происходит, даже когда сертификат клиента подписан другим CA (другая цепочка), чем серверный сертификат.

Данный пример отнесен к Приветствие сервера и Сертификат, представленный в предыдущем снимке экрана. Для того сценария сертификат ISE подписан CA с использованием имени субъекта, CN=win2012, dc=example, dc=com. Но сертификат пользователя, установленный в хранилище Microsoft, подписан другим CA, CN=CA, C=PL, S=Cisco CA, L=Cisco CA, CA. O=Cisco

В результате соискатель Microsoft Windows отвечает сертификатом клиента только. CA, который подписывает его (CN=CA, S=PL, S=Cisco CA, L=Cisco CA, O=Cisco CA) не подключен.

Из-за этого поведения AAA-серверы могли бы встретиться с проблемами, когда они проверяют сертификаты клиента. Пример касается Microsoft Windows 7 Профессионалов SP1.

Решение

Полная цепочка сертификатов должна быть установлена на хранилище сертификата ACS и ISE (весь CA и sub, CA подписав сертификаты клиента).

Проблемы с проверкой достоверности сертификата могут быть легко обнаружены на ACS или ISE. Информация о недоверяемом сертификате представлена и отчёты о ISE:

12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain

Проблемы с проверкой достоверности сертификата на соискателе не легко обнаруживаемы. Обычно AAA-сервер отвечает что "Оконечная точка abondoned сеанс EAP":

NAM AnyConnect

NAM AnyConnect не имеет этого ограничения. В том же сценарии это подключает завершенную цепочку сертификата клиента (корректный CA подключен):

Собственный соискатель Microsoft Windows наряду с NAM AnyConnect

Когда оба сервиса подключены, NAM AnyConnect имеет приоритет. Даже когда сервис NAM не работает, он все еще зацепляет API Microsoft Windows и вперед пакеты EAP, которые могут вызвать проблемы для Собственного соискателя Microsoft Windows. Вот пример такого сбоя.

Вы позволяете отследить на Microsoft Windows с этой командой:

C:\netsh ras set tracing * enable

Трассировки (c:\windows\trace\svchost_RASTLS.LOG) показывают:

[2916] 09-14 21:29:11:254: >> Received Request (Code: 1) packet: Id: 55, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[2916] 09-14 21:29:11:254: << Sending Response (Code: 2) packet: Id: 55, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[1804] 09-14 21:29:11:301: >> Received Request (Code: 1) packet: Id: 56, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[1804] 09-14 21:29:11:301: << Sending Response (Code: 2) packet: Id: 56, Length:
6, Type: 13, TLS blob length: 0. Flags:
[1804] 09-14 21:29:11:348: >> Received Request (Code: 1) packet: Id: 57, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[1804] 09-14 21:29:11:348: << Sending Response (Code: 2) packet: Id: 57, Length:
6, Type: 13, TLS blob length: 0. Flags:
[1804] 09-14 21:29:11:363: >> Received Request (Code: 1) packet: Id: 58, Length:
344, Type: 13, TLS blob length: 0. Flags:
[1804] 09-14 21:29:11:363: << Sending Response (Code: 2) packet: Id: 58, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM
[3084] 09-14 21:31:11:203: >> Received Request (Code: 1) packet: Id: 122, Length:
6, Type: 13, TLS blob length: 0. Flags: S
[3084] 09-14 21:31:11:218: << Sending Response (Code: 2) packet: Id: 122, Length:
105, Type: 13, TLS blob length: 95. Flags: L
[3420] 09-14 21:31:11:249: >> Received Request (Code: 1) packet: Id: 123, Length:
1012, Type: 13, TLS blob length: 2342. Flags: LM
[3420] 09-14 21:31:11:249: << Sending Response (Code: 2) packet: Id: 123, Length:
6, Type: 13, TLS blob length: 0. Flags:
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 124, Length:
1008, Type: 13, TLS blob length: 0. Flags: M
[3420] 09-14 21:31:11:281: << Sending Response (Code: 2) packet: Id: 124, Length:
6, Type: 13, TLS blob length: 0. Flags:
[3420] 09-14 21:31:11:281: >> Received Request (Code: 1) packet: Id: 125, Length:
344, Type: 13, TLS blob length: 0. Flags:
[3420] 09-14 21:31:11:296: << Sending Response (Code: 2) packet: Id: 125, Length:
1492, Type: 13, TLS blob length: 1819. Flags: LM

Последним пакетом является Сертификат клиента (фрагмент EAP-TLS 1 с размером EAP 1492) передаваемый Собственным соискателем Microsoft Windows. К сожалению, Wireshark не показывает что пакет:

И тот пакет действительно не передан (последний был третьим фрагментом серверного сертификата переноса EAP-TLS). Это было использовано модулем NAM AnyConnect, который зацепляет API Microsoft Windows.

Именно поэтому не рекомендуется использовать AnyConnect наряду с Собственным соискателем Microsoft Windows. При использовании любых сервисов AnyConnect рекомендуется использовать NAM также (когда сервисы 802.1x необходимы), не Собственный Соискатель Microsoft Windows.

Фрагментация

Фрагментация могла бы произойти на нескольких уровнях:

  • IP
  • Пары значения атрибута RADIUS (AVP)
  • EAP-TLS

Коммутаторы Cisco IOS® очень интеллектуальны. Они могут понять форматы EAP-TLS и EAP. Несмотря на то, что коммутатор не в состоянии дешифровать туннель TLS, это ответственно за фрагментацию, и блок и повторную сборку пакетов EAP когда инкапсуляция в Расширяемом протоколе аутентификации по LAN (EAPoL) или RADIUS.

Протокол EAP не поддерживает фрагментацию. Вот выборка от (EAP) RFC 3748:

"Фрагментация не поддерживается в самом EAP; однако, отдельные методы EAP могут поддержать это".

EAP-TLS является таким примером. Вот выборка от (EAP-TLS) RFC 5216, разделите 2.1.5 (фрагментация):

"Когда узел EAP-TLS получает Пакет запроса EAP с установленным битом M, это, MUST отвечает Ответом EAP с EAP-Type=EAP-TLS и никакие данные. Это служит ACK фрагмента. MUST сервера EAP ждет, пока это не получает Ответ EAP прежде, чем передать другой фрагмент".

Последнее предложение описывает очень важную функцию AAA-серверов. Они должны ждать ACK, прежде чем они смогут передать другой фрагмент EAP. Подобное правило используется для соискателя:

"Узел EAP, MUST ждет, пока он не получает Запрос EAP прежде, чем передать другой фрагмент".

Фрагментация в IP - уровне

Фрагментация может произойти только между Устройством доступа к сети (NAD) и AAA-сервером (IP/UDP/RADIUS, используемый в качестве транспорта). Эта ситуация происходит, когда NAD (коммутатор Cisco IOS) пытается передать Запрос RADIUS, который содержит информационное наполнение EAP, которое больше тогда MTU интерфейса:

Большинство версий Cisco IOS не достаточно интеллектуально и не пытается собрать пакеты EAP, полученные через EAPoL и объединить их в Пакете RADIUS, который может поместиться в MTU физического интерфейса к AAA-серверу.

AAA-серверы более интеллектуальны (как представлено в следующих разделах).

Фрагментация в RADIUS

Это не действительно никакой вид фрагментации. Согласно RFC 2865, одиночный атрибут RADIUS может иметь до 253 байтов данных. Из-за этого информационное наполнение EAP всегда передается во множественных атрибутах RADIUS сообщения EAP:

Те атрибуты сообщения EAP повторно собраны и интерпретированы Wireshark ("Последний Сегмент" атрибут показывает информационное наполнение целого пакета EAP). Заголовок Длины в пакете EAP является равным to1,012, и четыре AVP RADIUS требуются, чтобы транспортировать его.

Фрагментация в EAP-TLS

От того же снимка экрана вы видите что:

  • Длина пакета EAP 1,012
  • Длина EAP-TLS 2,342

Это предполагает, что это - первый фрагмент EAP-TLS, и соискатель должен ожидать больше, который может быть подтвержден, если вы исследуете флаги EAP-TLS:

Этот вид фрагментации наиболее часто происходит в:

  • Проблема доступа к серверу RADIUS, передаваемая AAA-сервером, который несет Запрос EAP с Серверным сертификатом Уровня защищенных сокетов (SSL) с целой цепочкой.
  • Access-Request RADIUS передает NAD, который несет Ответ EAP с Сертификатом Клиента SSL с целой цепочкой.

Подтверждение фрагмента EAP-TLS

Как объяснено ранее, каждый фрагмент EAP-TLS должен быть подтвержден, прежде чем последующие фрагменты передаются.

Вот пример (захваты пакета для EAPoL между соискателем и NAD):

Кадры EAPOL и AAA-сервер возвращают серверный сертификат:

  • Тот сертификат передается во фрагменте EAP-TLS (пакет 8).
  • Соискатель подтверждает что фрагмент (пакет 9).
  • Второй фрагмент EAP-TLS передан NAD (пакет 10).
  • Соискатель подтверждает что фрагмент (пакет 11).
  • Третий фрагмент EAP-TLS передан NAD (пакет 12).
  • Соискатель не должен подтверждать это; скорее это продолжает сертификат клиента, который запускается в пакете 13.

Вот подробные данные пакета 12:

Вы видите что повторно собранные пакеты Wireshark 8, 10, и 12. Размер фрагментов EAP is1,002, 1,002, и 338, который приносит общий размер сообщения EAP-TLS к 2342 (об общей длине сообщения EAP-TLS объявляют в каждом фрагменте). Это может быть подтверждено при исследовании Пакетов RADIUS (между NAD и AAA-сервером):

Пакеты RADIUS 4, 6, и 8 переносов те три фрагмента EAP-TLS. Первые два фрагмента подтверждены. Wireshark в состоянии представить информацию о фрагментах EAP-TLS (размер: 1,002 + 1,002 + 338 = 2,342).

Этот сценарий и пример были легки. Коммутатор Cisco IOS не должен был изменять размер фрагмента EAP-TLS.

Фрагменты EAP-TLS , повторно собранные с другим размером

Рассмотрите то, что происходит, когда MTU NAD к AAA-серверу составляет 9,000 байтов (кадр большого размера), и AAA-сервер также связан с использованием интерфейса, который поддерживает кадры большого размера. Большинство типичных соискателей связано с использованием 1Gbit ссылка с MTU 1,500.

В таком сценарии коммутатор Cisco IOS выполняет EAP-TLS "assymetric" блок и повторная сборка и изменяет размеры фрагментов EAP-TLS. Вот пример для большого сообщения EAP, передаваемого AAA-сервером (Сертификат SSL - сервера):

  1. AAA-сервер должен передать сообщение EAP-TLS с Сертификатом SSL - сервера. Общий размер того пакета EAP 3,000. После того, как это будет инкапсулироваться в RADIUS Access-Challenge/UDP/IP, это - еще меньше, чем максимальный размер блока данных (MTU) интерфейса AAA-сервера. Одиночный пакет IP передан с 12 атрибутами сообщения EAP RADIUS. Нет никакой фрагментации IP ни EAP-TLS.

  2. Коммутатор Cisco IOS получает такой пакет, декапсулирует его и решает, что EAP должен быть передан через EAPoL соискателю. Так как EAPoL не поддерживает фрагментацию, коммутатор должен выполнить фрагментацию EAP-TLS.

  3. Коммутатор Cisco IOS готовит первый фрагмент EAP-TLS, который может вписаться в MTU интерфейса к соискателю (1,500).

  4. Этот фрагмент подтвержден соискателем.

  5. Другой фрагмент EAP-TLS передается после того, как подтверждение получено.

  6. Этот фрагмент подтвержден соискателем.

  7. Последний фрагмент EAP-TLS передается коммутатором.

Этот сценарий показывает что:

  • При некоторых обстоятельствах NAD должен создать фрагменты EAP-TLS.
  • NAD ответственен за передачу/подтверждение тех фрагментов.

Та же ситуация может произойти для соискателя, связанного через ссылку, которая поддерживает кадры большого размера, в то время как AAA-сервер имеет меньший MTU (тогда, коммутатор Cisco IOS создает фрагменты EAP-TLS, когда это передает пакет EAP к AAA-серверу).

Обрамленный MTU атрибута RADIUS

Для RADIUS существует атрибут Обрамленного MTU, определенный в RFC 2865:

"Этот Атрибут указывает на Максимальный размер передаваемого блока данных, который будет настроен для пользователя, когда об этом не выполняют согласование некоторые другие средства (такие как PPP). Это MAY использоваться в Пакетах подтверждения доступа. Это MAY использоваться в Пакете запроса доступа в качестве подсказки NAS к серверу, что это предпочло бы, что значение, но сервер не требуется, чтобы соблюдать подсказку".

ISE не соблюдает подсказку. Значение Обрамленного MTU, передаваемого NAD в Access-Request, не оказывает влияния на фрагментацию, выполненную ISE.

Множественные современные коммутаторы Cisco IOS не позволяют, что изменения к MTU Интерфейса Ethernet за исключением параметров настройки кадров большого размера включили глобально на коммутаторе. Конфигурация кадров большого размера влияет на значение атрибута Обрамленного MTU, передаваемого в Access-Request RADIUS. Например, вы устанавливаете:

Switch(config)#system mtu jumbo 9000

Это вынуждает коммутатор передать Обрамленный MTU = 9000 во всех Access-request RADIUS. То же для system MTU без кадров большого размера:

Switch(config)#system mtu 1600

Это вынуждает коммутатор передать Обрамленный MTU = 1600 во всех Access-request RADIUS.

Заметьте, что современные коммутаторы Cisco IOS не позволяют вам уменьшать значение system MTU ниже 1,500.

AAA-серверы и поведение соискателя, когда вы передаете фрагменты EAP

ISE

ISE всегда пытается передать фрагменты EAP-TLS (обычно Приветствие сервера с Сертификатом), которые 1,002 байта длиной (невзирая на то, что последний фрагмент обычно меньше). Это не соблюдает Обрамленный MTU RADIUS. Не возможно реконфигурировать его для передачи больших фрагментов EAP-TLS.

Сервер политик сети Microsoft (NPS)

Возможно настроить размер фрагментов EAP-TLS при настройке атрибута Обрамленного MTU локально на NPS.

Событие, хотя Настраивание Объема полезных данных EAP на статье Microsoft NPS упоминает, что значение по умолчанию обрамленного MTU для сервера RADIUS NPS 1,500, Центр технической поддержки Cisco (TAC) лабораторная работа, показало, что передает 2,000 с настройками по умолчанию (подтвержденный на Центре обработки данных Microsoft Windows 2012 года).

Это протестировано, что установку Обрамленного MTU локально согласно ранее упомянутому руководству уважает NPS, и это фрагментирует сообщения EAP во фрагменты набора размера в Обрамленном MTU. Но атрибут Обрамленного MTU, полученный в Access-Request, не используется (то же в качестве на ISE/ACS).

Установка этого значения является допустимым обходным путем для устранения проблем в топологии как это:

Соискатель [MTU 1500]-------[MTU 9000] Коммутатор [MTU 9000]---------[MTU 9000] NPS

В настоящее время коммутаторы не позволяют вам устанавливать метрическую тонну на порт; для 6880 коммутаторов эта опция добавлена с идентификатором ошибки Cisco CSCuo26327 - EAP-TLS 802.1x, не работающий на порты хоста FEX.

AnyConnect

AnyConnect передает фрагменты EAP-TLS (обычно Сертификат клиента), которые 1,486 байтов длиной. Для этого размера значения Фрейм Ethernet составляет 1,500 байтов. Последний фрагмент обычно меньше.

Собственный соискатель Microsoft Windows

Microsoft Windows передает фрагменты EAP-TLS (обычно Сертификат клиента), которые являются 1,486 или 1,482 байта длиной. Для этого размера значения Фрейм Ethernet составляет 1,500 байтов. Последний фрагмент обычно меньше.

Дополнительные сведения



Document ID: 118634