33장. SIP 보안의 이해 (하)

1. S/MIME (Secure /  Multipart Internet Mail Extension)

S/MIME는 SDP를 암호화하거나 SIP 메시지에 대한 서명과 무결성을 제공합니다. SIP 헤더는 평문이지만 SIP 메시지 바디는 암호화합니다. 

INVITE sip:bob@biloxi.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Max-Forwards: 70
Contact: <sip:alice@pc33.atlanta.com>
Content-Type: application/pkcs7-mime;smime-type=enveloped-data; name=smime.p7m
Content-Disposition: attachment;filename=smime.p7m  handling=required 


JB23LB645V73V73MNB73KV7K4VLHV4T234T2T2JH5NG5CMGX5MYM5SMN5GYCWG5CYMWYMWHNHG5MC5YGWC5CW5WIU87W34TO8W7FLW5LWC5WC5C4L5CLWCTYWJHC54JHCW45HCWLJ5HCWL5CLWJH5CLJH4C5JHEWCLTJ

Content-Type 헤더의 application/pkcs7-mime 값이 SIP 메시지 바디가 S/MIME 임을 가리킵니다. S/MIME는 SHA1 인증과 3 DES 암호화 알고리즘을 사용합니다. S/MIME를 사용하는 이유는 단대단(End-to-End) 보안을 제공하기 위한 제한적인 상황에서 이용합니다. SIP 시그널링 전달 과정에 SIP Proxy 서버는 내용을 알 수 없으로 SIP Proxy서버가 있어야 수행할 수 있는 부가 서비스는 사용할 수 없습니다. 현장에서 거의 쓰이지 않습니다. 

2. Network Asserted Identity/Privacy (Trusted) 

도메인 내에서 사용자 인증은 Digest Authentication을 이용하고, 사용자 식별은 Network Asserted Identity를 이용합니다. 사용자를 식별하기 위해 세 가지 SIP 헤더가 필요합니다.

P-Asserted-Identity (PAI) : SIP Proxy 서버가 생성
PAI 헤더는 신뢰할 수 있는 SIP 컴포넌트 간에 사용되며 SIP 메시지를 보내는 사용자를 식별합니다. From 헤더는 SIP Proxy서버와 같은 SIP 컴포 터넌트들에 의해 추가 변경 삭제가 가능하므로 정확한 사용자 식별이 불가능합니다. PAI 헤더는 생성 이후에는 변경이 불가능하며 From 헤더보다 우선순위가 높습니다. PAI헤더는 SIP Proxy 서버가 사용자를 인증하고 생성하는 헤더이므로 신뢰성이 높습니다. 주로 과금 정보 생성에 활용됩니다. 

P-Preferred-Identity (PPI) :UAC가 생성
PPI 헤더는 신뢰할 수 있는 도메인 내에서 UAC가 선호하는 URI를 지정합니다. UAC가 신뢰할 수 있는 SIP Proxy 서버에게 SIP Message를 보내는 자신의 정확한 ID를 명기합니다.   

Privacy 
Privacy 헤더는 P-Asserted-Identity 헤더를 추가할지 삭제할지를 결정합니다. 만일 Privacy 헤더가 없으면 임의대로 결정합니다. 
- id  : 신뢰할 수 없는 도메인으로 SIP 메시지를 전달할 때 P-Asserted-Identity 헤더를 삭제
- none : 신뢰할 수 없는 도메인으로 SIP 메시지를 전달할 때 그대로 전달 

NAI는 신뢰할 수 있는 SIP 서버 네트워크가 인증된 사용자를 식별하고 상호 간에 프라이버시를 형성합니다. SIP Proxy 서버는 PAI 헤더를 가진 SIP 메시지는 신뢰할 수 있으므로 인증 대신 사용할 수 있습니다. PAI를 가진 SIP 메시지는 SIP Digest Authentication 이 SIP Proxy 서버에 의해 수행된 것이므로 SIP Proxy 서버를 신뢰할 수 있으면 가능합니다. 따라서, Privacy 설정으로 단순히 PAI를 전송할지 말지를 결정하는 것이 아니라 상호 간의 신뢰가 담보되는지 않는 지를 사전에 관리자가 확인하는 것이 중요합니다. 자세한 사항은 RFC 3325 Private Extensions to the SIP for Asserted Identity within Trusted Networks에 정의되어 있습니다. 

<그림 33-1> NAI

1) 앨리스의 INVITE

앨리스는 오드리와 통화하기 위해 SIP Proxy 서버로 INVITE를 전송합니다.

INVITE sip:audrey@atlanta.com SIP/2.0 
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK74b43
Max-Forwards: 70
From: <sip:anonymous@anonymous.invalid>;tag=9fxt6c
To: Audrey <sip:audrey@atlanta.com>
Call-ID: 3848276298220188511@pc33.atlanta.com
CSeq: 31862 INVITE
P-Preferred-Identity: Alice <sip:alice@atlanta.com>
Privacy: none
Content-Type: application/sdp
Content-Length: 151 

From 헤더는 anonymous(익명)으로 표시하고, P-Preferred-Identity 헤더에 앨리스의 사용자 정보를 포함합니다. P-Preferred-Identity 헤더가 From를 우선하기 때문에 From 헤더의 값은 무시됩니다. Privacy 헤더는 P-Asserted-Identity 헤더를 사용할지 말 지를 표시합니다. 

2) SIP Proxy 서버의 407 Proxy Authorization Required

SIP Proxy 서버는 사용자 인증 정보 요청을 위해 407 응답을 합니다. 

SIP/2.0 407 Proxy Authorization Required
Via: SIP/2.0/TLS pc33.atlanta.com;branch=z9hG4bK74b43
From: <sips:anonymous@anonymous.invalid>;tag=9fxt6c
To: Audrey <sips:audrey@atlanta.com>;tag=3flal
Call-ID: 3848276298220188511@pc33.atlanta.com
CSeq: 31862 INVITE
Proxy-Authenticate:...(메시지 생략)
Content-Length: 0

앨리스는 SIP Digest Authentication을 위해 정보를 요청합니다.

3) 앨리스의 INVITE (Token과 PPI)

앨리스는 Authorization 헤더에 Digest Authentication 관련 사용자 정보를 포함하고, P-Preferred-Identity 헤더에 사용자 정보를 포함하여 전달합니다.  

INVITE sips:audrey@atlanta.com SIP/2.0 
Via: SIP/2.0/TLS pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
Route: <sips:bigbox10.atlanta.com;lr>
To: Audrey <sips:audrey@atlanta.com>
From: <sips:anonymous@anonymous.invalid>;tag=19jtf0
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 31863 INVITE
P-Preferred-Identity: Alice <sips:alice@atlanta.com>
Privacy: id
Content-Type: application/sdp
Content-Length: 151
Authorization:... (메시지 생략)  

SIP URI 가 SIPS URI로 변경되었으므로 TLS 세션으로 전달됩니다. Privacy 헤더의 값이 'none'에서 'id'로 변경되었으므로 SIP Proxy 서버에게 신뢰할 수 없는 도메인으로는 P-Assorted-Identity를 전송하지 말 것을 요청합니다.   

4) SIP Proxy 서버의 INVITE (Token과 PAI)

SIP Proxy 서버는 앨리스의 사용자 인증을 수행하고 INVITE 요청을 오드리에게 전달합니다. 

INVITE sips:audrey@atlanta.com SIP/2.0 
Via: SIP/2.0/TLS Bigbox10.atlanta.com;branch=z9hG4bKnashd92
Via: SIP/2.0/TLS pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 69 
To: Audrey <sips:audrey@atlanta.com>
From: <sips:anonymous@anonymous.invalid>;tag=19jtf0
Call-ID: a84b4c76e66710
CSeq: 31863 INVITE
P-Asserted-Identity: Alice <sips:alice@atlanta.com>
Privacy: id
Content-Type: application/sdp
Content-Length: 151
Authorization:... (메시지 생략) 

3. SIP Identity

같은 도메인 내의 사용자 인증은 Digest Authentication과 사용자 식별은 Network Assorted Identity를 이용합니다. 서로 다른 도메인 간에 사용자 식별을 위한 방안이 필요합니다. 도메인과 도메인 간을 건너갈 때 상대방이 보내 준 발신자의 사용자 식별자를 어떻게 신뢰할 수 있는지가 문제입니다. 예를 들어, 발신자가 보낸 SIP INVITE 요청이라고 보내진 메시지를 다른 도메인에 있는 밥이 신뢰할 수 있는 방법이 필요합니다.

INVITE sips:bob@biloxi.com SIP/2.0 
Via: SIP/2.0/TCP pc33.atlanta.com;branch=z9hG4bK74b43
Max-Forwards: 70
From: <sips:alice@atlanta.com>;tag=9fxt6c
To: Bob <sips:bob@biloxi.com>
Call-ID: 3848276298220188511@pc33.atlanta.com
CSeq: 31862 INVITE
Date: Sun, 22 Jun 2008 20:02:03 GMT
Contact: <sip:alice@atlanta.com>
Identity: "CyI4+nAkHrH3ntmaxgr01TMxTmtjP7MASwliNRdupRI1vpkXRvZXx1ja 9k0nB2sW+v1PDsy32MaqZi0M5WfEkXxbgTnPYW0jIoK8HMyY1VT7egt0kk4 XrKFCHYWGClsM9CG4hq+YJZTMaSROoMUBhikVIjnQ8ykeD6UXNOyfI="
Identity-Info: <https://atlanta.com/cert02.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 151 

SIP Protocol은 새로운 두 개의 SIP 헤더를 이용하여 해결합니다 

Identity 헤더
해쉬값으로 SIP 헤더와 SDP 정보가 중간에 변경되었다면 Identity 헤더의 헤쉬 값과 일치하지 않으므로 문제가 발생합니다. 

Identity-info
바로 전 SIP 컴포넌트의 인증서를 얻을 수 있는 URL

SIP Identity는 From, Contact, Via, Call-ID, Record-Route 등에 사용한 메시지 발송자의 이름이 변경되지 않았음을 증명합니다. 변경되지 않았음을 증명하는 identity의 헤쉬 값과 비교하기 위해서는 Idnetity-info 가 가리키는 URL에서 인증서를 다운로드하여야 하며, 사용된 헤쉬 알고리즘이 무엇인지를 확인합니다.

4. SIP Privacy

신뢰할 수 없는 도메인으로 SIP 요청을 전달할 경우에 UAC를 식별할 수 있는 모든 메시지를 제거합니다. 

INVITE sips:bob@biloxi.com SIP/2.0
Via: SIP/2.0/TLS agent86.privacy-service.com;branch=z9hG4bKnashd93
Max-Forwards: 69
To: Bob <sips:bob@biloxi.com>
From: <sips:anonymous@anonymous.invalid>;tag=19jtf1
Call-ID: a84b4c76e66711
CSeq: 31863 INVITE
Contact: <sips:anonymous@anonymous.invalid>
Content-Type: application/sdp
Content-Length: 151
Authorization:... (메시지 생략) 

INVITE 메시지에서 앨리스가 전송한 것을 인지할 수 있는 모든 메시지 부분을 'anonymous@anonymous.invalid'로 변경하였습니다. 응답 메시지는 Via 헤더를 따라 전달되고, From 헤더의 고유한 tag 파라미터를 통하여 식별합니다. 

'엔지니어를 위한 인터넷 전화와 SIP의 이해'를 책으로 만들다

https://brunch.co.kr/@linecard/188

책으로 출판합니다.