이 글을 쓰게 된 계기는 시스코 제품 소개에 치중한 글이 너무 많아 엔지니어에게 도움이 되지 않을 것이다라는 따끔한 질책을 받았서 입니다. 항상 블로그의 올바른 방향을 제시하는 허클베리핀님 덕에 블로그의 초심을 잃을 뻔했던 마음을 다잡게 됩니다. "지식은 소유되지 않고 공유되어야 한다"라는 믿음으로 열심히 공부하면서 포스팅하겠습니다.
엔지니어 입장에서 틀린부분은 과감하게 댓글달아 주시면 바로 고치는 라인하트입니다.^^ 가끔 비밀댓글로 달아 주시는 분들이 계신데 혹시나 하는 기대감(?)에 열어보지만 역시나 틀린부분 수정이라 실망을 합니다 -,-:?. 수정사항은 바로 올려주시기 바랍니다 제가 게으를 경우 글을 보는 다른 들이 잘못된 지식이 전해질 수 있습니다.
“SIP의 이해” 연재 이후 “SIP 보안” 부분을 정리하려고 했지만, 실제 업무에서 활용되지 않다 보니 시간이 많이 걸렸습니다. 여기에 정리된 내용은 이미 많이 사용되고 있으며, 인터넷 상에서도 공유되고 있는 내용입니다. SIP 보안 관련하여 고민하시는 분들에게 도움이 되길 바랍니다.
시작하며
우리가 전화 통화를 할 경우를 생각해 봅시다. 아래 그림과 같이 Alice가 Bob에게 전화를 걸면, Alice는 IP Phone으로 Bob은 소프트 폰으로 전화를 받습니다. Alice와 Bob은 둘 사이에는 아무것도 없고, 아무것도 사이에 존재하지 않는다고 생각할 것입니다.
엔지니어의 입장에서 하나의 빨간 선으로 이루어진 부분을 돋보기로 확대해 보겠습니다. 아래 그림처럼 라우터, 스위치, SIP Proxy, Firewall, NAT 등의 다양한 장비들이 보입니다. 또한, 다수의 SIP Proxy 서버를 거치고, 다수의 도메인을 넘어서 통신할 것입니다.
Alice와 Bob의 생각대로 안전하다고 믿을 수 있는 보안정책이 필요합니다. 보안에 대한 고려없이는 두 사람이 편하게 대화할 수 없으므로 신뢰할 수 있는 방안이 제시되어야 할 것입니다.
다양한 SIP 보안 방법
SIP에서 제공하는 보안을 위한 방법들은 다음과 같습니다.
- Digest Authentication (발신자 인증)
같은 도메인 내에서 적용되어 발신자를 인증하기 위해 사용하는 방식으로 가장 많이 사용합니다. HTTP에서 사용되는 인증방식으로 재사용 공격 방지와 인증을 제공합니다.
- TLS/IPSec
Hop by Hop 또는 End-to-End로 Signaling에 대한 기밀성과 무결성을 보장합니다.
- S/MIME (Secure / Multipurpose Internet Mail Extension)
SIP 메세지 바디는 MIME으로 구성되어 있으며, 이 메세지를 암호화하여 기밀성 및 무결성을 제공합니다.
- Network Asserted Identity (NAI)
같은 도메인 내의 사용자를 식별합니다.
- SIP Identity
NAI가 같은 도메인 내에서 발신측을 식별하였다면, SIP Identity는 도메인과 도메인간에 발신측을 인증합니다.
- SIP Privacy
외부 도에인에 대해 메세지의 특정 부분을 보호합니다.
실제 위의 방법들은 서로 동시에 사용됩니다. 각각에 대해 차근차근 이해해 보도록 하겠습니다.
SIP Digest Authentication
SIP Digest 인증은 INVITE, REGISTER 등과 같은 요청에 대해 서버는 nonce라고 하는 난수 문자열을 생성하여 전송합니다. UAC는 사용자 이름, 암호 및 NONCE를 포함하는 MD5 Hash로 응답합니다. 주고 받는 메세지 내에서 사용자 이름과 암호를 확인하기 어렵기 때문에 발신자에 대한 인증과 재사용(Replay)공격을 방지할 수 있습니다. 이 인증 방법은 HTTP Digest Authentication을 기반으로 하여 RFC 2617에 자세히 나와 있습니다. 여기서, 사용자 이름과 암호는 고유하며, 쌍방간에 사전에 교환되었음을 가정합니다. 따라서, 신뢰할 수 있는 도메인 내에서만 사용되는 것입니다.
아래 그림은 Alice가 Audrey에게 통화를 시도하는 Call Flow입니다. “SIP의 이해” 이후 직접 메세지를 분석하는 것은 오랜만입니다. SIP 메세지 분석을 가끔 하다보니 할 때 마다 햇갈립니다. –,-:? 점점 SIP 실력이 줄어드는 느낌입니다.
Alice의 INVITE를 받은 SIP Proxy 서버는 407 Proxy Auth Req 에러 메세지를 전송합니다. 만일 SIP Redirect 나 Registra Server라면, 401 Unauthoried라는 에러 메세지를 전송합니다. 여기서 Proxy-Authenticate 헤더는 인증에 필요한 정보를 포함하여 INVITE를 재전송할 것을 요구하는 것입니다.
Proxy-Authenticate: Digest realm="atlanta.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5
복잡한 내용이지만, 엔지니어가 모든 것을 알아야 할 필요는 없습니다. - 사실 저도 잘 모릅니다. -,-:? - realm 파라미터는 도메인 네임을 의미하며, qop=”auth” 파라미터는 사용자 인증 요청을 의미입니다. nonce은 시간을 기반으로 만들어진 문자 난수열이며, MD5로 헤쉬 되었습니다.
407 Proxy Auth Req 에러 메세지를 받은 Alice는 Authorization 헤더를 포함하여 INVITE를 재전송하며, 수신한 SIP Proxy 서버는 INVITE를 보낸 발신자가 앨리스가 맞다는 것을 확인한는 것입니다. 알고나면 단순하지만, 모르면 고생하는 Digest 인증입니다.
만일 2개의 SIP Proxy를 경우는 Digest 인증은 다음과 같은 호 흐름을 사용합니다. Proxy Server 1의 인증요청에 인증 메세지와 Proxy Server 2의 인증요청에 따른 인증 요청 메세지를 포함하여 전송하는 것입니다.
SIPS(TLS) : Hop-by-Hop Security
보다 안전한 TLS를 활용한 방법을 살펴보겠습니다. SIP Proxy 서버가 SIP Message를 추가 변경 삭제가 가능할 뿐만 아니라 항상 메세지 내용을 확인해야 하기 때문에 Alice와 Bob간의 End-to-End로 암호화를 하는 것이 어렵습니다. 그래서, Hop-by-Hop으로 처리될 수 밖에 없습니다. 아래 그림에서 처럼 Alice의 전화기와 Proxy 1 간에 TLS를 이용하여 암호화를 수행하고, 복호화한 후에 다시 암호화하여 Proxy2로 전송하는 과정을 반복해야 합니다.
TLS는 Transport Layer Security의 약자이며, 두 통신 시스템간의 데이타 무결성과 기밀성을 제공합니다. TLS를 활용한 SIPS는 다음과 같은 몇 가지 특징이 있습니다.
- TLS는 TCP와 같은 신뢰할 수 있는 전송프로토콜 위에서 동작합니다.
- 데이터 암호화를 위해 DES와 같은 Symmetric 암호화를 사용합니다.
- 암호화 키는 connection마다 유일합니다.
- MD5나 SHA 헤쉬로 메세지 무결성을 나타냅니다.
- 서버와 클라이언트간에 상호 인증을 수행합니다.
- TLS는 AES@128bit 를 사용해야 합니다.
S/MIME
S/MIME는 SDP를 암호화하거나 SIP 전체 메세지에 대한 서명, 무결성을 제공할 수 있습니다. 아래 그림은 Alice가 Bob에게 INVITE를 보내는 과정을 나타낸 것이며, SDP 부분이 암호화되어 있습니다.
위 SIP 메세지 중에 Content-Type 헤더는 application/pkcs7-mime 라는 파라미터는 S/MIME임을 가리키고 있습니다. S/MIME는 SHA1 인증과 3 DES 암호화 알고리즘을 사용합니다. S/MIME는 SDP가 암호화되어 End-to-End간 즉, Alice와 Bob 만이 이해할 수 있습니다. 따라서, 중간에서 SDP 메세지를 이해해야 하는 서비스 즉, Redirect 또는 Forking과 같은 서비스를 같이 사용할 수 없는 것이 단점입니다.
Network Asserted Identity/Privacy (Trusted)
도메인 내에서 Digest 가 사용자를 인증한다면, NAI는 사용자 식별을 위해 사용되는 매커니즘입니다. 같은 의미입니다만 구체적으로는 약간의 차이가 있습니다.
위의 그림에서 Alice가 Audrey에게 INVITE를 전송하는 과정입니다. 즉, UAC가 보내는 INVITE 메세지입니다. 내용을 간단히 살펴보면, From 헤더는 anonymous 로 표시되고 P-Preferred-Identity 헤더에 사용자 정보가 포함됩니다. Privacy 헤더는 “none”으로 표시되어 P-Asserted-Identity가 있던 없던 상관하지 않겠다는 의미입니다. 여기서 From 헤더가 anonymous로 표시된 것은 P-Preferred-Identity가 우선적으로 사용되기 때문입니다.
여기에서 Network Asserted Idetity에 관련된 주요 헤더에 대해 살펴보겠습니다.
- P-Asserted-Identity (PAI)
이 헤더는 신뢰할 수 있는 SIP Entity사이에 사용되며, SIP message를 보내는 사용자를 확인합니다. 이 헤더는 From 헤더와 달리 다른 값으로 변경이 불가능하며 우선순위가 더 높아 From의 값보다는 PAI 값을 사용합니다. 서버 측에서 인증하고 생성하는 P-Asserted-Identity가 과금 정보에 주로 사용됩니다.
- P-Preferred-Identity (PPI)
이 헤더는 신뢰할 수 있는 도메인 내에서 UAC가 선호하는 URI를 지정합니다. 즉, UAC가 신뢰할 수 있는 Proxy Server 에게 SIP Message를 보내는 자신의 정확한 ID 를 명기하는 것입니다.
- Privacy
Privacy에” id”가있으면, 신뢰할 수 없는 곳으로 SIP Message를 전달할 때 P-Asserted-Identity Header를 삭제하고 전달해야 하며, “none”으로 표시되면 삭제하지 않고 전달합니다. 만일, Privacy 헤더가 없다면, P-Asserted-Identity 헤더의 추가 또는 삭제를 마음대로 할 수 있습니다.
아래 그림은 SIP Proxy 서버가 407 에러를 전송하여 Digest 인증을 요청하였습니다.
재전송되는 INVITE 메세지를 보시면, “INVITE sips:audrey@atlanta.com SIP/2.0” 로 변경되어 SIPS URI를 사용하며, TLS 또는 IPsec이 사용된다는 것을 알 수 있습니다. 위의 메세지에서 Privercy 헤더의 파라미터 “none”에서 “id”로 변경되었습니다. 즉, Proxy Server에게 신뢰할 수 없는 곳으로는 P-Assorted-Identity를 전송하지 말라고 요청합니다.
Digest 인증을 통해 SIP Proxy 서버는 Alice를 인증하였으며, Audrey는 같은 도메인내에 존재하는 신뢰할 수 있는 사용자이므로 P-Asserted-identity를 추가하여 INVITE Message를 전송합니다.
지금까지 NAI (Network Asserted Identity)의 메커니즘을 살펴보았으며, RFC 3325 Private Extensions to the SIP for Asserted Identity within Trusted Networks 에 자세히 나와 있습니다. 몇 장 되지 않기에 읽어보시기 바랍니다. 여기에 설명된 내용을 간략히 정리해 보겠습니다.
- NAI는 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자들을 식별해주며, 그들간에 프라이버시 형성할 수 있도록 해줍니다.
- SIP Server가 P-Asserted-Identity 헤더를 가진 신뢰할 수 있는 Entity로 부터 SIP 메세지를 받는 다면, 새로운 Digest 인증과정을 거치는 대신에 인증목적으로 이 필드를 사용할 수 있습니다.
- SIP Server가 신뢰할 수 없는 곳으로 메세지를 전송할 때 PAI 헤더를 제거한다면, Privacy 헤더 값은 “id”로 설정됩니다.
- UAS가 PAI 헤더를 포함한 메세지를 받다면, From 헤더 보다 더 신뢰합니다. 그래서 일반적으로 From 헤더를 <anonymous>로 설정합니다.
지금까지 도메인 내에서의 보안방법을 살펴보았습니다. 다음 하편에서는 나머지 SIP Identity와 SIP Privacy는 도메인과 도메인간의 보안 방법을 살펴보겠습니다.
마치며
귀차니즘으로 정리하지 못했던 것을 마치니 뿌듯합니다. 요즘 Nexpert 블로그의 업데이트가 매우 늦다라고 생각할 것입니다. 사실 허클베리핀님과 솔민아빠님이 너무 바쁘십니다. 그렇다고 제가 한가한 것은 아닙니다. ^^ 저도 직장이 있는 몸이라 돈이 되는 일에 매진하고 있습니다.
다음주면 즐거운 한가위입니다. 다들 한가위 잘 보내시고, 올해 계획했던 일들을 모두 성취하시길 바랍니다. 이번 한가위에 연초에 세운 계획들을 점검해 보시고, 포기할 건 포기하는 전략을 취할 시점이네요… 저도 포기하는 중입니다. -,-:?
----------------------------------------------
라인하트 (CCIEV #18487)
ucwana@gmail.com (라인하트의 새로운 구글 이메일)
http://twitter.com/ucwana (라인하트의 트위터 )
http://twitter.com/nexpertnet (넥스퍼트 블로그의 트위터, 최신 업데이트 정보 및 공지 사항)
http://groups.google.com/group/cciev (시스코 UC를 공부하는 사람들이 모인 구글 구룹스)
http://groups.google.com/group/ucforum (벤더에 상관없이 UC를 공부하는 사람들이 모인 구글 구룹스)
http://cafe.nexpert.net/ (체계적인 UC 정보의 전달 및 나눔을 위한 카페)
정리하고 보니 나도 디지털 네이티브 ^____________^
