EAP 조각화 구현 및 동작
목차
소개
이 문서에서는 EAP(Extensible Authentication Protocol) 세션을 이해하고 문제를 해결하는 방법에 대해 설명합니다.이러한 문제는 다음과 같습니다.
- AAA(Authentication, Authorization, and Accounting) 서버가 EAP-TLS(Extensible Authentication Protocol-Transport Layer Security) 세션에 대한 서버 인증서를 반환할 때의 동작
- 서 플리 컨 트가 EAP-TLS 세션에 대한 클라이언트 인증서를 반환 할 때 하는 동작
- Microsoft Windows 네이티브 서 플리 컨 트 및 Cisco AnyConnect NAM(Network Access Manager)를 모두 사용하는 경우 상호 운용성
- IP, RADIUS 및 EAP-TLS의 프래그먼트화 및 네트워크 액세스 장치에 의해 수행되는 리어셈블리 프로세스
- RADIUS MTU(Framed-Maximum Transmission Unit) 특성
- AAA 서버가 EAP-TLS 패킷의 단편화를 수행할 때 수행하는 동작
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
- EAP 및 EAP-TLS 프로토콜
- Cisco ISE(Identity Services Engine) 구성
- Cisco Catalyst 스위치의 CLI 구성
이 문서를 이해하려면 EAP 및 EAP-TLS를 잘 이해해야 합니다.
서버에서 반환된 인증서 체인
AAA 서버(ACS(Access Control Server) 및 ISE)는 항상 서버 Hello 및 서버 인증서를 사용하여 EAP-TLS 패킷의 전체 체인을 반환합니다.
ISE ID 인증서(CN(Common Name)=lise.example.com)는 CN=win2012,dc=example,dc=com에 서명한 CA(Certificate Authority)와 함께 반환됩니다.ACS와 ISE의 동작은 동일합니다.
신청자가 반환한 인증서 체인
Microsoft Windows 기본 신청자
EAP-TLS를 사용하기 위해 구성된 Microsoft Windows 7 기본 신청자는 "단순 인증서 선택"과 함께 또는 없이 클라이언트 인증서의 전체 체인을 전송하지 않습니다.이 동작은 클라이언트 인증서가 서버 인증서와 다른 CA(다른 체인)에 의해 서명된 경우에도 발생합니다.
이 예는 이전 스크린샷에 제시된 Server Hello 및 Certificate와 관련이 있습니다.이 시나리오의 경우 ISE 인증서는 주체 이름 CN=win2012,dc=example,dc=com을 사용하여 CA에 의해 서명됩니다.그러나 Microsoft 저장소에 설치된 사용자 인증서는 다른 CA, CN=CA,C=PL,S=Cisco CA,L=Cisco CA, O=Cisco CA에 의해 서명됩니다.
따라서 Microsoft Windows 신청자는 클라이언트 인증서만 응답합니다.서명하는 CA(CN=CA,S=PL,S=Cisco CA, L=Cisco CA, O=Cisco CA)가 연결되어 있지 않습니다.
이러한 동작으로 인해 AAA 서버가 클라이언트 인증서를 검증할 때 문제가 발생할 수 있습니다.이 예제는 Microsoft Windows 7 SP1 Professional과 관련이 있습니다.
솔루션
ACS 및 ISE의 인증서 저장소(모든 CA 및 하위 CA 서명 클라이언트 인증서)에 전체 인증서 체인을 설치해야 합니다.
인증서 검증 문제는 ACS 또는 ISE에서 쉽게 탐지할 수 있습니다.신뢰할 수 없는 인증서에 대한 정보가 표시되고 ISE는 다음을 보고합니다.
12514 EAP-TLS failed SSL/TLS handshake because of an unknown CA in the client
certificates chain
서 플리 컨 트의 인증서 검증 문제를 쉽게 감지 할 수 없습니다.일반적으로 AAA 서버는 "엔드포인트가 EAP 세션을 허용하지 않음"에 응답합니다.
AnyConnect NAM
AnyConnect NAM에는 이러한 제한이 없습니다.동일한 시나리오에서 클라이언트 인증서의 전체 체인을 연결합니다(올바른 CA가 연결됨).
AnyConnect NAM과 함께 Microsoft Windows 네이티브 서 플리 컨 트
두 서비스가 모두 작동하면 AnyConnect NAM이 우선적으로 적용됩니다.NAM 서비스가 실행되지 않는 경우에도 Microsoft Windows API를 후크하고 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
마지막 패킷은 Microsoft Windows 기본 신청자가 보낸 클라이언트 인증서(EAP 크기 1492의 EAP-TLS 프래그먼트 1)입니다.안타깝게도 Wireshark는 해당 패킷을 표시하지 않습니다.
그리고 해당 패킷은 실제로 전송되지 않습니다(마지막 패킷은 EAP-TLS 전송 서버 인증서의 세 번째 조각임). Microsoft Windows API를 후크하는 AnyConnect NAM 모듈에 의해 사용되었습니다.
따라서 Microsoft Windows 네이티브 서 플리 컨 트와 함께 AnyConnect를 사용하지 않는 것이 좋습니다.AnyConnect 서비스를 사용할 때는 Microsoft Windows 네이티브 서 플리 컨 트가 아닌 NAM(802.1x 서비스가 필요할 때)도 사용하는 것이 좋습니다.
조각화
조각화는 여러 레이어에서 발생할 수 있습니다.
- IP
- RADIUS 특성 값 쌍(AVP)
- EAP-TLS
Cisco IOS® 스위치는 매우 지능적입니다.EAP 및 EAP-TLS 형식을 이해할 수 있습니다.스위치는 TLS 터널을 해독할 수 없지만, EAPoL(Extensible Authentication Protocol over LAN) 또는 RADIUS에서 캡슐화할 때 프래그먼트화 및 EAP 패킷의 어셈블리 및 재어셈블리에 대한 책임이 있습니다.
EAP 프로토콜은 조각화를 지원하지 않습니다.다음은 RFC 3748(EAP)의 인용문입니다.
"조각화는 EAP 자체 내에서 지원되지 않습니다.그러나 개별 EAP 방법이 이를 지원할 수 있습니다."
EAP-TLS가 그러한 예입니다.다음은 RFC 5216(EAP-TLS), 섹션 2.1.5(fragmentation)에서 발췌한 내용입니다.
"EAP-TLS 피어가 M 비트가 설정된 EAP-Request 패킷을 수신할 경우 EAP-Type=EAP-TLS와 함께 EAP-Response로 응답하고 데이터가 없어야 합니다.이는 프래그먼트 ACK로 사용됩니다.EAP 서버는 다른 프래그먼트를 보내기 전에 EAP-응답을 받을 때까지 기다려야 합니다."
마지막 문장은 AAA 서버의 매우 중요한 기능에 대해 설명합니다.다른 EAP 조각을 전송하려면 먼저 ACK를 기다려야 합니다.신청자에 유사한 규칙이 사용됩니다.
"EAP 피어는 다른 프래그먼트를 전송하기 전에 EAP 요청을 수신할 때까지 기다려야 합니다."
IP 레이어의 단편화
프래그먼트화는 NAD(Network Access Device)와 AAA 서버(전송으로 사용되는 IP/UDP/RADIUS) 간에만 발생할 수 있습니다. 이 상황은 NAD(Cisco IOS 스위치)가 EAP 페이로드를 포함하는 RADIUS 요청을 보내려고 시도할 때 발생합니다. 이는 인터페이스의 MTU보다 큽니다.
대부분의 Cisco IOS 버전은 충분히 지능적이지 않으며 EAPoL을 통해 받은 EAP 패킷을 어셈블하지 않고 물리적 인터페이스의 MTU에 AAA 서버를 연결하는 RADIUS 패킷에 결합합니다.
AAA 서버는 더 지능적입니다(다음 섹션에 나와 있음).
RADIUS의 조각화
이것은 정말로 어떤 종류의 단편화가 아닙니다.RFC 2865에 따라 단일 RADIUS 특성은 최대 253바이트의 데이터를 가질 수 있습니다.따라서 EAP 페이로드는 항상 여러 EAP-Message RADIUS 특성으로 전송됩니다.
이러한 EAP-Message 특성은 Wireshark에 의해 재조합되고 해석됩니다("Last Segment" 특성은 전체 EAP 패킷의 페이로드를 나타냅니다). EAP 패킷의 Length 헤더는 1,012이며, 전송하려면 4개의 RADIUS AVP가 필요합니다.
EAP-TLS의 단편화
동일한 스크린샷에서 다음을 볼 수 있습니다.
- EAP 패킷 길이는 1,012입니다.
- EAP-TLS 길이는 2,342입니다.
이것은 첫 번째 EAP-TLS 프래그먼트이며 신청자는 더 많은 것을 기대해야 한다는 것을 의미하며, 이는 EAP-TLS 플래그를 검사하면 확인될 수 있습니다.
이러한 종류의 프래그먼트화는 다음에서 가장 자주 발생합니다.
- AAA 서버에서 보낸 RADIUS 액세스 - SSL(Secure Sockets Layer) 서버 인증서와 함께 EAP 요청을 전체 체인으로 전달합니다.
- RADIUS Access-Request는 NAD에 의해 전송되며, SSL 클라이언트 인증서와 함께 EAP-Response를 전체 체인으로 전달합니다.
EAP-TLS 프래그먼트 확인
앞에서 설명한 대로 모든 EAP-TLS 프래그먼트는 후속 프래그먼트가 전송되기 전에 승인되어야 합니다.
다음은 예시입니다(신청자와 NAD 간의 EAPoL에 대한 패킷 캡처).
EAPoL 프레임 및 AAA 서버는 서버 인증서를 반환합니다.
- 해당 인증서는 EAP-TLS 프래그먼트(패킷 8)로 전송됩니다.
- 신청자는 프래그먼트(패킷 9)를 승인합니다.
- 두 번째 EAP-TLS 프래그먼트는 NAD(패킷 10)에 의해 전달됩니다.
- 신청자는 프래그먼트(패킷 11)를 승인합니다.
- 세 번째 EAP-TLS 프래그먼트는 NAD(패킷 12)에 의해 전달됩니다.
- 신청자가 이를 승인할 필요는 없습니다.대신 패킷 13에서 시작하는 클라이언트 인증서를 사용합니다.
패킷 12의 세부 정보는 다음과 같습니다.
Wireshark가 8, 10 및 12로 리어셈블된 패킷을 확인할 수 있습니다. EAP 프래그먼트의 크기는 1,002, 1,002 및 338이며, 총 EAP-TLS 메시지 크기를 2342로 가져옵니다(모든 프래그먼트에 총 EAP-TLS 메시지 길이가 발표됨). RADIUS 패킷(NAD와 AAA 서버 간)을 검사한 경우 이를 확인할 수 있습니다.
RADIUS 패킷 4, 6 및 8은 이러한 3개의 EAP-TLS 프래그먼트를 전달합니다.처음 두 개의 프래그먼트가 확인됩니다.Wireshark는 EAP-TLS 프래그먼트에 대한 정보를 제공할 수 있습니다(크기:1,002 + 1,002 + 338 = 2,342).
이 시나리오와 예는 쉬웠습니다.Cisco IOS 스위치는 EAP-TLS 프래그먼트 크기를 변경할 필요가 없습니다.
EAP-TLS 프래그먼트가 다른 크기로 다시 어셈블됨
AAA 서버에 대한 NAD MTU가 9,000바이트(점보 프레임)이고 AAA 서버가 점보 프레임을 지원하는 인터페이스 사용과 연결되어 있을 때 발생하는 상황을 고려하십시오.대부분의 일반적인 신청자는 MTU 1,500를 사용하는 1Gbit 링크를 사용하여 연결됩니다.
이러한 시나리오에서 Cisco IOS 스위치는 EAP-TLS "assymetric" 어셈블리를 수행하고 다시 어셈블하고 EAP-TLS 프래그먼트 크기를 변경합니다.다음은 AAA 서버(SSL Server Certificate)에서 보낸 대규모 EAP 메시지의 예입니다.
- AAA 서버는 SSL 서버 인증서와 함께 EAP-TLS 메시지를 보내야 합니다.해당 EAP 패킷의 총 크기는 3,000입니다. RADIUS Access-Challenge/UDP/IP에 캡슐화된 후에도 AAA 서버 인터페이스 MTU보다 작습니다.단일 IP 패킷은 12 RADIUS EAP-Message 특성을 사용하여 전송됩니다.IP 또는 EAP-TLS 단편화가 없습니다.
- Cisco IOS 스위치는 이러한 패킷을 수신하고 이를 역캡슐화하며 EAPoL을 통해 서 플리 컨 트에 EAP를 전송 해야 한다고 결정 합니다.EAPoL은 조각화를 지원하지 않으므로 스위치는 EAP-TLS 조각화를 수행해야 합니다.
- Cisco IOS 스위치는 인터페이스의 MTU에 맞는 첫 번째 EAP-TLS 프래그먼트를 신청자(1,500)에게 준비합니다.
- 이 프래그먼트는 신청자에 의해 확인됩니다.
- 승인을 받은 후 다른 EAP-TLS 프래그먼트가 전송됩니다.
- 이 프래그먼트는 신청자에 의해 확인됩니다.
- 마지막 EAP-TLS 프래그먼트는 스위치에 의해 전송됩니다.
이 시나리오에서는 다음을 보여줍니다.
- 경우에 따라 NAD는 EAP-TLS 프래그먼트를 생성해야 합니다.
- NAD는 이러한 프래그먼트를 전송/승인하는 업무를 담당합니다.
점보 프레임을 지원하는 링크를 통해 연결된 서 플리 컨 트에 대해 동일한 상황이 발생할 수 있으며 AAA 서버에 더 작은 MTU가 있습니다(그런 다음 Cisco IOS 스위치는 EAP 패킷을 AAA 서버로 전송할 때 EAP-TLS 프래그먼트를 생성합니다).
RADIUS 특성 Framed-MTU
RADIUS의 경우 RFC 2865에 정의된 Framed-MTU 특성이 있습니다.
"이 속성은 PPP와 같은 다른 방법으로 협상되지 않은 경우 사용자에 대해 구성할 최대 전송 단위를 나타냅니다. Access-Accept 패킷에서 사용할 수 있습니다.NAS가 해당 값을 선호하는 서버에 대한 힌트로 Access-Request 패킷에서 사용할 수 있지만, 힌트를 준수하기 위해 서버가 필요하지 않습니다."
ISE는 힌트를 승인하지 않습니다.Access-Request에서 NAD에 의해 전송된 Framed-MTU 값은 ISE에 의해 수행되는 조각화에 영향을 주지 않습니다.
여러 최신 Cisco IOS 스위치는 스위치에서 전역적으로 활성화된 점보 프레임 설정을 제외하고 이더넷 인터페이스의 MTU를 변경할 수 없습니다.점보 프레임 컨피그레이션은 RADIUS Access-Request에서 전송되는 Framed-MTU 특성 값에 영향을 줍니다.예를 들어 다음을 설정합니다.
Switch(config)#system mtu jumbo 9000
그러면 스위치에서 모든 RADIUS 액세스 요청에서 Framed-MTU = 9000을 보냅니다.점보 프레임 없이 시스템 MTU에서도 동일합니다.
Switch(config)#system mtu 1600
그러면 스위치에서 모든 RADIUS 액세스 요청에서 Framed-MTU = 1600을 보냅니다.
최신 Cisco IOS 스위치로는 시스템 MTU 값을 1,500 이하로 줄일 수 없습니다.
EAP 프래그먼트를 전송할 때 AAA 서버 및 신청자 동작
ISE
ISE는 항상 1,002바이트 길이의 EAP-TLS 프래그먼트(일반적으로 Server Hello with Certificate)를 보내려고 시도합니다(마지막 프래그먼트는 보통 더 작지만). RADIUS Framed-MTU는 적용되지 않습니다.더 큰 EAP-TLS 프래그먼트를 전송하도록 재구성할 수 없습니다.
Microsoft NPS(네트워크 정책 서버)
NPS에서 로컬로 Framed-MTU 특성을 구성하는 경우 EAP-TLS 프래그먼트의 크기를 구성할 수 있습니다.
Microsoft NPS에서 EAP 페이로드 크기 구성 문서에서 NPS RADIUS 서버에 대한 프레임드 MTU의 기본값이 1,500이라고 언급하는 경우, Cisco TAC(Technical Assistance Center) 랩에서는 기본 설정(Microsoft Windows 2012 데이터 센터에서 확인)을 사용하여 2,000을 보내는 것으로 나타났습니다.
NPS는 앞서 언급한 가이드에 따라 로컬로 프레임-MTU를 설정하는 것을 테스트하고, EAP 메시지를 프레임-MTU에 설정된 크기의 조각으로 분할합니다.그러나 Access-Request에서 받은 Framed-MTU 특성은 사용되지 않습니다(ISE/ACS에서와 동일).
이 값을 설정하면 다음과 같은 토폴로지 문제를 해결할 수 있습니다.
신청자 [MTU 1500] — [MTU 9000]스위치[MTU 9000] — [MTU 9000]NPS
현재 스위치에서는 포트당 MTU를 설정할 수 없습니다.6880 스위치의 경우 이 기능은 Cisco 버그 ID CSCuo26327 - 802.1x EAP-TLS가 FEX 호스트 포트에서 작동하지 않는 상태로 추가됩니다.
AnyConnect
AnyConnect는 1,486바이트 길이의 EAP-TLS 프래그먼트(일반적으로 클라이언트 인증서)를 전송합니다.이 값 크기의 이더넷 프레임은 1,500바이트입니다.마지막 프래그먼트는 보통 더 작다.
Microsoft Windows 기본 신청자
Microsoft Windows는 1,486 또는 1,482바이트 길이의 EAP-TLS 프래그먼트(일반적으로 클라이언트 인증서)를 전송합니다.이 값 크기의 이더넷 프레임은 1,500바이트입니다.마지막 프래그먼트는 보통 더 작다.
피드백