내가 이해했듯이 EAP-TTLS와 PEAP는 무선 네트워크에서 구현 될 때 동일한 수준의 보안을 공유합니다. 둘 다 인증서를 통한 서버 측 인증 만 제공합니다.

EAP-TTLS의 단점은 Microsoft Windows에서 기본적으로 지원되지 않으므로 모든 사용자가 추가 소프트웨어를 설치해야합니다.

EAP-TTLS의 이점은 덜 안전한 인증 메커니즘 (PAP, CHAP, MS-CHAP)을 지원할 수 있지만 현대적이고 적절하게 안전한 무선 시스템에 필요한 이유는 무엇입니까?

당신의 의견은 무엇입니까? PEAP 대신 EAP-TTLS를 구현해야하는 이유는 무엇입니까? 대부분의 Windows 사용자, 중간 Linux 사용자 및 최소 iOS, OSX 사용자가 있다고 가정 해 봅시다.

RADIUS 백엔드가 지원하는 경우 두 가지를 모두 지원할 수 있습니다. 그러나 일부 클라이언트는 "자동"-연결 (예 : Mac OS X> = 10.7 + iOS)하며 둘 이상의 유형을 지원하는 경우 클라이언트 중 하나가 작동 할 때까지 서로 다른 조합을 시도하기 때문에 최적의 상태보다 덜 작동 할 수 있습니다. 연결하는 한 가지 방법 만 있으면 번거 로움이 줄어 듭니다.

기본적으로 PEAP 만 지원하거나 TTLS가 필요한 클라이언트가있는 경우 PEAP + TTLS를 지원하십시오.

고객 제한

• 아이폰 OS 클라이언트는 지원하지 않습니다 EAP-TTLS와 PAP(전용 MsCHAPv2프로파일을 설치)를하지 않는 한 수동 (컴퓨터를 통해).

• Windows 클라이언트 는 EAP-TTLSIntel 무선 카드가없는 경우 기본적으로 지원하지 않습니다 (secure2w와 같은 소프트웨어를 설치해야 함).

• Android 는 EAP및의 거의 모든 조합을 지원 PEAP합니다.

비밀번호 데이터베이스 제한

따라서 실제 문제는 비밀번호 저장 방법입니다.

그들이있는 경우 :

• Active Directory 를 사용하면 EAP-PEAP-MsCHAPv2(Windows 박스) 및 EAP-TTLS-MsCHAPv2(iOS 클라이언트와 함께 )를 사용할 수 있습니다 .

• LDAP에 비밀번호를 저장 하면 EAP-TTLS-PAP(Windows 상자)를 사용할 수 있지만 iOS에 대한 정보는 유실됩니다.

중요한 보안 문제

• 모두 EAP-TTLS와 PEAP사용 TLS(전송 계층 보안)를 통해 EAP(확장 할 수있는 인증 프로토콜).

아시다시피 TLS최신 버전이며 SSL신뢰할 수있는 중앙 기관 (CA)에서 서명 한 인증서를 기반으로 작동합니다.

TLS터널 을 설정하려면 클라이언트가 올바른 서버와 통신하고 있는지 확인해야합니다 (이 경우 사용자를 인증하는 데 사용되는 반경 서버). 서버가 신뢰할 수있는 CA에서 발급 한 유효한 인증서를 제공했는지 확인하여이를 수행합니다.

문제는 : 일반적으로 신뢰할 수있는 CA에서 발급 한 인증서가 없지만이 목적을 위해 만든 임시 CA에서 발급 한 인증서가있는 것입니다. 운영 체제는 CA와 사용자 (귀하의 지시에 따라)가이를 행복하게 받아 들일 것임을 사용자에게 불평합니다.

그러나 이것은 주요 보안 위험을 초래합니다.

누군가는 회사 내부 (가방 또는 랩톱)에 불량 AP를 설정하고 자신의 반경 서버 (랩톱 또는 자체 불량 AP에서 실행)와 통신하도록 구성 할 수 있습니다.

클라이언트가이 AP가 더 강력한 신호를 가지고 있다고 판단하면 액세스 포인트에 연결을 시도합니다. 알 수없는 CA (사용자 동의)를보고, TLS터널 을 설정하고 ,이 터널에서 인증 정보를 보내면 로그 반경이 로그에 기록됩니다.

이제 중요한 부분 : 일반 텍스트 인증 체계 ( PAP예 :)를 사용하는 경우 불량 반지름 서버가 사용자 비밀번호에 액세스 할 수 있습니다.

인증 기관에서 발급 한 유효한 인증서를 사용하여 iOS, Windows (및 Android) 트러스트 모두 해결할 수 있습니다. 또는 CA 루트 인증서를 사용자에게 배포하고 인증서 문제가 발견 될 경우 연결을 거부하도록 알려줄 수 있습니다 (행운을 빕니다).

PEAPv0, PEAPv1 및 TTLS의 보안 속성은 동일합니다.

PEAP는 EAP를 운반하는 EAP를 둘러싼 SSL 래퍼입니다. TTLS는 RADIUS 인증 속성을 전달하는 지름 TLV 주변의 SSL 래퍼입니다.

백엔드 인증 데이터베이스가 되돌릴 수없는 해시 형식 (예 : bigcrypt 또는 MSCHAP (NT-OWF)과 호환되지 않는 모든 형식)으로 자격 증명을 저장하는 경우 EAP-TTLS-PAP가 EAP-PEAP보다 유용 할 수 있습니다. CHAP 기반 방법 중 하나

EAP-PEAPv1-GTC를 사용하여 PAP를 에뮬레이션 할 수도 있지만 이것은 클라이언트가 널리 지원하지는 않습니다.

PEAP는 PEAP 버전 협상 두통과 PEAPv1의 역사적 비 호환성 (PRF에서 마스터 키를 가져올 때의 클라이언트 마법과 같은) 형태로 TTLS를 초과하는 수하물을 추가하여 초기 구현에 나섰습니다.

필자는 일반적으로 랩톱 컴퓨터와 모바일 핸드셋에서 더 많이 사용하는 PEAP를 사용하는 무선 장비의 가입자 모듈과 같은 임베디드 클라이언트에 EAP-TTLS가 구현되어있는 것을보고 있습니다.

EAP-TTLS는 기존에 타사 소프트웨어를 설치하지 않고 Windows 클라이언트에서 지원되지 않았습니다. EAP-TTLS는 이제 Windows 8부터 지원됩니다.

몇 가지 추가 생각 :

EAP-TTLS는 RADIUS 공급 업체에서 개발했습니다. EAP-PEAPv0은 Microsoft에서 발명했습니다. EAP-PEAPv1은 IETF 프로세스에서 나왔습니다.

내부 인증 방법에 대한 암호화 바인딩을 통해 시스템을보다 안전하게 만드는 PEAPv2에 대한 추가 IETF 작업이있었습니다. 이것은 내가 알 수있는 한 가까이에 가지 않았습니다.

디스크 먹는 사람이 쓴 것처럼 사람들이 TTLS를 사용하는 주된 이유는 반경 서버가 일반 텍스트 암호를 그러한 방식으로 볼 수 있도록 허용하므로 인증 백엔드에 따라 유용 할 수 있기 때문입니다.

PEAP를 선호하는 새로운 고려 사항은 SoH는 AFAICT가 RADIUS 서버에 요청하는 경우에만 RAIUS 서버에만 제공되며 Microsoft 시스템에서 요청하는 유일한 방법은 PEAP 세션 중이라는 것입니다. 따라서 에이전트없는 평가에서 에이전트와 같은 평가를 받으려면 (아마도 더 많은 AV 공급 업체에서 지원할 예정 임) PEAP를 원할 것입니다. 그러나 알몸의 암호를 사용하여 1 단계 OAUTH 백엔드를 해결하려는 경우 내부 터널 서비스를 제공하지 않는 대형 IDP는 TTLS를 사용하여 사용자가 입력 할 수있는 단서가 없습니다.

클라이언트가 기본적으로 지원하는 EAP 방법과 추가 소프트웨어를 사용하는 방법 및 서버가 지원하는 내부 인증 방법을 고려해야합니다.

PEAP 및 EAP-TTLS는 서버 식별의 유효성을 검사 할 수 있도록 설계되었지만 클라이언트가 인증서의 유효성을 검사하도록 올바르게 구성되어 있는지 확인해야합니다.

PEAP 및 MS-CHAPv2는 클라이언트에서 잘 지원되지만 서버가 일반 텍스트 암호를 저장하지 않기 때문에 MS-CHAPv2를 지원하지 않는 경우 다른 솔루션을 만들어야합니다. 이것이 사람들이 EAP-TTLS와 PAP를 사용하는 주된 이유입니다.

자동 연결은 두 옵션 모두에서 도움이 될 것이라고 생각합니다. 더 많은 옵션은 번거롭지 않습니다. 자동 연결에서 TTLS-PAP를 먼저 시도한 다음 PEAP-MSCHAP를 시도하면 TTLS-PAP을 사용할 수있어 자동 연결이 더 빨라집니다. 기본적으로 두 가지를 모두 지원하면 단점을 볼 수 없습니다.

ttls를 통해 일반 텍스트 암호를 사용하는 pap는 MSCHAP의 보안이 손상되었으므로 ( "crack mschap"에 대한 Google) PEAP-MSCHAP와 동일한 보안 수준을 갖습니다.

EAP-TTLS와 PEAP의 보안 차이에 대해서는 잘 모르므로 기본적으로 PEAP가 승자 인 지원이 필요합니다.