SIP는 HTTP 인증 방식에 기반을 둔 stateless, challenge-based 인증 매커니즘을 제공한다.
Inbound
Proxy Server 또는 UAS가 SIP 요청 메시지를 수신하면 UAC에게 identity assurance 제공을
요청한다. UAC가 인증되면 해당 SIP 요청을 수신한 UAS는 UAC가 권한이 있는지를 확인해야 한다.
HTTP 인증 방식에는 앞서 잠깐 언급하였듯이 Digest Mechanism과 Basic Mechanism 두 종류가 있다. 이 두방식에 대해 간략히 알아보자.
Basic Mechanism
HTTP 인증 방식중 Basic Mechanism은 사용자 ID와 패스워드를 일반 텍스트 기반으로 인증하는 방식이다. 이 방식은 사용하기 쉽고 간편하게 이용할 수 있지만, 사용자 ID와 패스워드는 유출될 가능성의 소지가 있다.
Digest Mechanism
이 방식은 Basic Mechanism과 마찬가지로 사용자 ID와 패스워드를 기반으로 클라이언트를 인증하는 방식이다. 다만 이 방식은 서버가 먼저 클라이언트에게 nonce 값을 할당하여 전송한다(challenge).
이를 수신한 클라이언트는 서버가 전송한 nonce 값의 체크섬(checksum)을 계산하여 해당 값을 다시 서버로 전송하여 인증절차를 밟는다(credentials).
보안이 필요한 시스템의 경우 상기에서 살펴본 바와 같이 Digest Mechanism(RFC 2617)을 사용하도록 하고, Basic Mechanism은 보안상 취약하여 사용시 면밀한 검토를 해야 한다.
다음은 SIP 인증 절차를 표현한 그림이다.
상기의 인증 절차를 단계별로 송수신되는 메시지를 예를 들어 기술하면 다음과 같다.
(1) REGISTER : UAC -> SIP Server
먼저 UAC가 SIP Server로 자기좀 등록해 달라고 SIP REGISTER 요청 메시지를 전송한다. 이때 전송되는 메시지 예는 다음과 같다.
REGISTER sip:sip.infravalley.comSIP/2.0
Via: SIP/2.0/UDP sonny.infravalley.com:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Monky <sip:sonny@infravalley.com>;tag=a73kszlfl
To: Monky <sip:sonny@infravalley.com>
Call-ID: 1j9FpLxk3uxtm8tn@sonny.infravalley.com
CSeq: 1 REGISTER
Contact: <sip:sonny@sonny.infravalley.com>
Content-Length: 0
(2) 401 Unauthorized : SIP Server -> UAC
UAC가 전송한
REGISTER 요청 메시지를 수신한 SIP Server는 해당 Authorization 헤더값을 체크한다. 만약
Authorization 헤더값이 설정되어 있지 않아 인증 정보가 없을 경우, SIP Server는 UAC에게 nonce
헤더값을 설정하여 challenge한다.
이때 SIP 메시지 상의 WWW-Authenticate 헤더값에 생성된 nonce 항목과 algorithm 항목에 암호화 알고리즘 방식등을 설정하여 UAC가 SIP Server로의 인증시 참조할 정보들을 기술한다. 이때 전송되는 메시지 예는 다음과 같다.
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP sonny.infravalley.com:5061;branch=z9hG4bKnashds7
;received=203.249.9.114
From: Monky <sip:sonny@infravalley.com>;tag=a73kszlfl
To: Monky <sip:sonny@infravalley.com>;tag=1410948204
Call-ID: 1j9FpLxk3uxtm8tn@sonny.infravalley.com
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm=”infravalley.com”,
nonce=”ea9c8e88df84f1cec4341ae6cbe5a359″,
opaque=””, stale=FALSE, algorithm=MD5
Content-Length: 0
(3) REGISTER : UAC -> SIP Server
UAC는 SIP Server가 전송한 nonce 값의 체크섬(checksum)을 계산하여 해당 값을 참조하여 SIP 메시지의 Authorization 헤더값을 설정한 후, 다시 서버로 전송하여 인증절차를 밟는다(credentials). 이때 전송되는 메시지 예는 다음과 같다.
REGISTER sip:sip.infravalley.comSIP/2.0
Via: SIP/2.0/UDP sonny.infravalley.com:5061;branch=z9hG4bKnashd92
Max-Forwards: 70
From: Monky <sip:sonny@infravalley.com>;tag=ja743ks76zlflH
To: Monky <sip:sonny@infravalley.com>
Call-ID: 1j9FpLxk3uxtm8tn@sonny.infravalley.com
CSeq: 2 REGISTER
Contact: <sip:sonny@sonny.infravalley.com>
Authorization: Digest username=”sonny”,
realm=”infravalley.com”nonce=”ea9c8e88df84f1cec4341ae6cbe5a359″,
opaque=””,uri=”sip:sip.infravalley.com”,
response=”dfe56131d1958046689d83306477ecc”
Content-Length: 0
(4) 200 OK : SIP Server -> UAC
UAC로부터 인증 정보가
재첨부된 SIP REGISTER 요청 메시지를 수신한 SIP Server는 수신된 인증 정보로 인증 과정이 문제없이 통과되었을
경우, UAC에게 인증이 성공적으로 완료되었음을 알리는 200 OK 메시지를 전송한다. 이때 전송되는 메시지 예는 다음과
같다.
SIP/2.0 200 OK
Via: SIP/2.0/UDP sonny.infravalley.com:5061;branch=z9hG4bKnashd92;received=203.249.9.114
From: Monky <sip:sonny@infravalley.com>;tag=ja743ks76zlflH
To: Monky <sip:sonny@infravalley.com>;tag=37GkEhwl6
Call-ID: 1j9FpLxk3uxtm8tn@sonny.infravalley.com
CSeq: 2 REGISTER
Contact: <sip:sonny@sonny.infravalley.com>;expires=3600
Content-Length: 0
