다이내믹 키를 만들고 배포하는 것 외에도 802.1x 표준은 세션의 키를 정기적으로 바꿔주고(rekey), 어카운팅을 위해 네트워크 액세스를 모니터링한다. 이것은 사용자 이름-패스워드 조합이나 전자 증명서와 같은 사용자 인증을 지원하기 때문에, 예를 들어 랩톱이 도난당했을 경우 도둑은 네트워크로부터 차단될 것이다. 802.1x 표준은 기존의 인증 시스템과 작동하기 때문에 각 클라이언트용으로 맞춤 소프트웨어를 필요로 하지 않는다.
이 표준은 EAP(Extensible Authentication Protocol)와 그 알고리즘을 이용해 인증 프로세스 동안 메시지를 상호교환한다. EAP(RFC 2284)가 지원하는 알고리즘들로는 MD5(Message Digest 5), TLS(Transport Layer Security), TTLS(Tunneled TLS), LEAP(Lightweight EAP) 및 PEAP(Protected EAP) 등이 있다.
그러나 802.1x라고 해서 무엇이든 막아주는 마법의 총탄은 아니다. 이것은 전자 증명서 관리를 필요로 하며, 그 작업은 간단하지 않다. 그리고 802.1x 클라이언트와 서버 소프트웨어는 서로간에 반드시 호환이 되어야 한다. 또한 아직 그 인증 알고리즘이 성숙하지 못하기 때문에 플러그 앤 플레이가 되지 않는다.
세 가지 구성 요소
802.1x 프로토콜에는 세 가지 요소들이 있다. 우선 요구자(supplicant)가 있는데, 이는 데스크톱, 랩톱, 혹은 PDA와 같이 보안 네트워크 액세스를 요하는 클라이언트 장비다. 그리고 인증자(authenticator)가 있는데 이는 무선 액세스 포인트나 네트워크 스위치와 같은 중간 장비가 될 수 있다. 이런 장비는 요구자와 세 번째 요소인 인증 서버간에 정보를 상호교환해준다. 인증 서버는 자체의 사용자 데이터베이스로 하거나 혹은 마이크로소프트의 액티브 디렉토리나 기타 LDAP 데이터베이스와 같은 외부 사용자 데이터베이스를 이용해 사용자를 인증해주는 래디우스 서버가 될 수 있다.
래디우스 서버는 802.1x 인증 서버로서 인기를 끌고 있는데, 그 이유는 대다수 기업에서 이들을 보안 다이얼인 사용자 액세스용으로 사용하고 있기 때문이다. 래디우스 서버가 있으면 사용자 정보를 각 액세스 포인트나 네트워크 스위치에 저장하지 않아도 된다. 이것은 중복성에도 또한 도움이 되는데, 주 서버가 잘못됐을 경우 백업 래디우스 서버가 인증 프로세스를 대신할 수 있기 때문이다. 래디우스는 일반적으로 사용되는 대부분의 EAP 인증 메커니즘(TLS, TTLS, LEAP, MD5 및 PEAP)을 지원한다.
802.1x용 래디우스 서버를 셋업하는 게 불가능한 소호 무선 환경에서는 사무실의 관리자나 집에서 일하는 사용자가 클라이언트와 액세스 포인트 양쪽에 모두 수동으로 입력된 사전 공유되는 키를 사용할 수 있다. 그러면 액세스 포인트는 WEP 키를 만들어서 사전 공유되는 키로 이것을 암호화하여 무선 클라이언트로 전송한다.
유선 랜에서의 인증
802.1x를 배치하는 조직들은 사용자 이름-패스워드 조합이나 보다 강력한 인증 방안을 이용해 자신들의 사용자를 랜에 대해 인증할 수 있다. 802.1x 인증은 알카텔이나 시스코시스템즈, 엔터라시스 네트웍스, 익스트림 네트웍스 및 파운드리 네트웍스 등과 같은 유명 스위치 업체들로부터 널리 사용 가능하다. 스위치(인증자)가 802.1x 지원 포트에 있는 링크의 다른 쪽에서 활성 클라이언트를 감지하면, 이것은 802.1x 인증 프로세스를 초기화한다.
우리는 최근 본지 시러큐스 대학 리얼월드 랩의 유선 이더넷 랜에서 802.1x 보안을 테스트해 보았다. 파운드리 네트웍스의 패스트아이언(FastIron 4802) 스위치는 802.1x 인증기였으며, 인증 서버는 IAS(Internet Authentication Services)가 있는 마이크로소프트 윈도 2000 어드밴스드 서버였다. IAS 서버에서 우리는 파운드리 스위치를 클라이언트 장비로 등록한 다음 정상 업무 시간에만 네트워크 액세스를 허용하도록 원격 액세스 정책을 설정했다.
인증 알고리즘으로는 MD5를 사용했으며, MD5는 단방향 해시(one-way hash) 기능과 수하(challenge)를 사용해서 요구자의 신원증명서를 확인하며, 이것은 802.1x 세계에서 가장 간단하게 사용할 수 있는 것이기도 하다. 하지만 무선 쪽에서는 보통 선택이 잘 안되고 있는데, 그 이유는 이것이 클라이언트 인증만 지원해서 불량 무선 AP에는 취약성을 남겨두기 때문이다.
802.1x는 모든 스위치 포트에서 기능 억제가 디폴트로 돼 있다. 따라서 우리는 파운드리 스위치의 명령어 라인 인터페이스를 이용하여 이것이 802.1x 클라이언트를 지원하는 포트에서 802.1x 인증을 하도록 구성했다.
또한 윈도 XP 클라이언트에서 802.1x 기능을 활성화시켰는데, 이를 위해서는 파운드리 스위치에서 802.1x 설정을 자동 모드로 바꿔야 했다. 이렇게 함으로써 사용자들은 EAP-MD5가 있는 윈도 XP 클라이언트가 포트로 접속된 후 802.1x로 인증할 수 있다. 그런 다음 802.1x는 네트워크에 접속되도록 사용자 이름과 패스워드를 입력하라고 한다. 우리의 랩 테스트는 전체적으로, 유선 802.1x가 배치와 구성이 간편하며, ACL(Access Control List)나 가상랜과 같은 기존의 보안 솔루션들과 잘 작동한다는 사실을 증명해 주었다.
무선에서의 인증
우리는 에어로넷 350(Aironet 350) 시리즈 카드, 시스코 1200 시리즈 액세스 포인트, 그리고 펑크(Funk)의 스틸벨티드(Steel-Belted) 래디우스 서버로 무선 802.1x와 LEAP을 테스트했다. 시스코 1200에서 LEAP을 구성하기 위해서는 래디우스 서버가 사용하게 될 포트뿐만 아니라 두 개의 장비가 공유하는 키까지도 지정해주어야 했다. 그리고 EAP 옵션도 또한 지원해야 했다.
한편, 래디우스 서버는 시스코 AP가 하나의 클라이언트로 추가될 것을 필요로 했다. 우리는 또한 공유되는 래디우스 키와 인증을 필요로 하는 사용자를 지정해야 했다. 사용자용으로 LEAP을 지원하기 위해서는 래디우스 서버의 ‘eap.ini’ 파일을 변경했다.
클라이언트 쪽에서는 네트워크로 안전하게 접속하기 위해 LEAP 보안 옵션을 선택하고 정확한 사용자 이름과 패스워드를 입력했다. LEAP은 증명서를 사용하는 몇몇 다른 복잡한 인증 방안들에 비해서 비교적 구성 작업이 수월한 편이다.
802.1x의 EAP-TLS 부분을 테스트하기 위해, 우리는 래디우스 인증용으로는 IAS(Internet Authentication Service)를, 사용자 데이터베이스용으로는 액티브 디렉토리를 돌리는 윈도 2000 어드밴스드 서버를 사용했다. EAP-TLS는 상호 인증용으로 전자 증명서를 사용하기 때문에 우리는 시러큐스 랩에 있는 기존의 CA(Certificate-Authority) 인프라를 이용했다.
이러한 구성에서, 래디우스 서버는 XP 클라이언트에게 자신의 전자 증명서를 보낸다. 그러면 클라이언트는 증명서 발급자와 그 내용을 점검한 다음 자신의 증명서를 래디우스 서버로 보낸다. 래디우스 서버는 같은 확인 절차를 거쳐 증명서의 발급자와 내용물을 확인한다. 마지막으로 클라이언트가 인증 확인 메시지를 받으면 그 클라이언트와 서버는 역동적 키를 확보하게 된다.
LEAP과 PEAP
한편 시스코는 인증 방안으로 LEAP에만 다 의존하지는 않으며, 마이크로소프트와 RSA 시큐리티와 함께, 개방형 표준인 PEAP을 개발했다. 이것은 이미 상용화돼 있는데 시스코는 PEAP을 자사 클라이언트에 내장시켰으며, 펑크의 오딧세이 클라이언트 2.0 또한 이것을 지원하고 있다. 마이크로소프트의 SP1(혹은 그 이상)이 있는 윈도 XP에도 PEAP 지원이 포함돼 있으며, 마이크로소프트는 윈도 2000용의 PEAP이 있는 802.1x 인증 클라이언트의 무료 다운로드를 제공하고 있다. 마이크로소프트의 프리미어 앤 얼라이언스(Premier and Alliance) 지원 계약을 통해 윈도 98과 NT 4.0용의 802.1x 클라이언트를 얻을 수도 있다.
우리는 또한 윈도 XP 클라이언트와 윈도 2000 어드밴스드 서버 기반 래디우스 서버를 이용해 802.1x용 PEAP을 테스트했다. SP1이 있는 윈도 XP 클라이언트는 MS-CHAPv2 알고리즘을 이용해 PEAP을 지원하는데, 이 알고리즘은 패스워드 기반이며 MD4, SHA-1(Secure Hash Algorithm) 및 DES (Data Encryption Standard) 알고리즘의 조합을 이용한다. EAP는 MS-CHAPv2 지원이 활성화돼 있을 때 지원해야 한다. 그러면 TLS 채널이 전체 상호교환 프로시저를 암호화하며, 래디우스 서버와 클라이언트는 MS-CHAPv2 수하 요청/응답을 교환하여 서로를 인증한다. 802.1x 이행에서 PEAP과 함께 EAP-TLS를 사용한다면 서버와 클라이언트 모두 증명서가 필요할 것이며, 이는 EAP-MS-CHAPv2가 있는 PEAP보다 더 복잡하긴 하지만 더 강력한 이행이기도 하다.
WPA로 임시 변통
802.1x 표준은 그 강력한 인증과 키 배포 및 교체 방안 덕분에 다가오는 무선 보안 802.11i 사양에서 큰 역할을 하게 될 것이다. 802.11i 표준이 최종 승인을 기다리고 있는 동안, Wi-Fi 얼라이언스에서는 임시 보안 표준안인 WPA(Wi-Fi Protected Access)를 내놓았는데, 이것 역시 802.1x의 기본틀을 이용해 인증을 한다. 무선 장비용의 간단한 펌웨어 업그레이드가 필요한 이 표준은 다가오는 802.11i 표준과도 호환이 된다.
유선 쪽에서는 집에서 작업하는 대부분의 사용자들이 VPN 세션을 이용해 기업 네트워크로 접속하고 있다. VPN과 802.1x는 좋은 짝을 이루는데, 802.1x가 있으면 방화벽과 IPsec 기반 VPN 보안이 타깃 공격을 훨씬 효과적으로 막아주기 때문이다. 802.1x는 비록 여전히 블루소켓(Bluesocket)이나 리프엣지(ReefEdge)와 같은 강력한 써드파티 업체 보안 제품들과 힘든 경쟁을 벌이고 있긴 하지만, 사용자들이 안전하게 네트워크 자원으로 액세스할 수 있게 해주는 가장 안전하고 간단한 방법으로 점차 각광받고 있다.
802.1x의 프로토콜들
802.1x 인증의 세계로 뛰어들려면 조심해야 할 것이 있다. 즉 LEAP, PEAP, TLS, TTLS 등 옵션이 너무도 많다는 사실이다. 이런 프로토콜들은 과연 무엇을 하는 것들일까?
LEAP은 EAP(Extensible Authentication Protocol)의 시스코 전용 버전으로, 전자 증명서 대신 강력한 수하-패스워드 해시 교환을 이용한다. 그러나 시스코는 공격자가 데이터로 침입하거나 802.1x EAP 인증 프로세스가 진행되는 동안 향후 공격을 위해 암호화되지 않은 사용자 정보를 캡처링하지 못하게 막는 것으로 가장 유명한 PEAP(Protected EAP) 개발을 위해 마이크로소프트 및 RSA 시큐리티와 힘을 합함으로써 보호막을 마련해두었다.
PEAP은 두 가지 단계로 작동한다. 클라이언트와 액세스 포인트간에 첫 핸드셰이크(handshake)가 끝나면, 클라이언트와 인증 서버간에 TLS(Transport Layer Security) 채널이 만들어진다. 모든 메시지가 암호화되면 래디우스 서버는 EAP 방안(EAP-TLS나 EAP-MS-CHAP[Challenge Handshake Authentication Protocol] v2)를 이용해 클라이언트를 인증한다.
TTLS(Tunneled Transport Layer Security)에서는 TLS 터널이 만들어지고 클라이언트 인증 패러미터들이 상호교환된다. TLS는 TTLS보다 나온 지가 오래되긴 했지만 각 클라이언트에서 추가 인증서를 필요로 하기 때문에 점차 사용이 줄어들고 있다.
TTLS와 PEAP은 개념상 유사하지만 중요한 차이점들이 있다. 즉 TTLS는 다른 EAP 인증 방안과 PAP, CHAP, MS-CHAP 및 MS-CHAPv2 등을 지원하는 반면, PEAP는 EAP-TLS, EAP-MS-CHAPv2 및 EAP-SIM과 같은 EAP 형태의 프로토콜만 터널링할 수 있다. 또한 TTLS는 클라이언트 소프트웨어 설치를 필요로 하는 반면 PEAP는 예를 들어 클라이언트 장비의 XP 서비스 팩 1에서 돌아갈 준비가 돼 있다. TTLS는 널리 사용 가능하고 이행되고 있지만, PEAP은 아직 나온 지가 얼마 되지 않은 새로운 방안이다. 그러나 PEAP이 시스코, 마이크로소프트 및 RSA의 지원을 받고 있다는 점을 감안한다면 이것이 802.1x의 디펙토 인증 메커니즘으로 부상할 가능성이 높다. 
