Post on 13-Jan-2016
description
SIP Security Issues :The SIP Authentication Procedure and its Processing Load
Speaker: Lin-Yi WuAdvisor : Prof. Yi-Bing LinDate : 2003/04/09
Main Reference
Salsano, S.; Veltri, L.; Papalilo, D , “SIP security issues: the SIP authentication procedure and its processing load “, IEEE Network , Volume: 16 Issue: 6 , Nov/Dec 2002
J. Rosenberg et al., “SIP: Session Initiation Protocol “ IETF RFC 3261, June 2002
Outline
Motivation Classification of security
End-to-End Hop-by-Hop
Security Support in SIP Authentication Encryption
Evaluation of Processing Cost Proposed solution
Requirements Limitation of current SIP security mechanism Design concept
Motivation
Achieve the same security level in PSTN High service availability
Prevent DOS, IDS, fault tolerance…etc. Protection of user-to-network and user-
to-user traffic Authentication Data Integrity Encryption
Classification of security mechanism
End-to-End mechanism Secure association between caller and callee user agent Protect any confidential information besides route infor
mation Hop-by-Hop mechanism
Secure association between two successive SIP entities in the path
Protect route information
UACUAS
SIP Server SIP Server
SIP Server
Security Support in SIP
End-to-End mechanism Defined in SIP protocol
Authentication Proxy-Authenticate, Proxy-Authorization, WWW-Authenti
cate, Authorization Encryption
S/MIME Hop-by-Hop mechanism
Rely on Network level or Transport Level security IPSec TLS
Evaluation of Authentication Processing Cost
Analysis :SIP Authentication Requirements
Requirements Authentication
Mutual Authentication Key Distribution Roaming agreement
Integrity Cipher Key exchange Prevention of replay attack
Limitation of current Authentication mechanism Authentication
Mutual Authentication : NO Key Distribution : Predefine secret Roaming agreement : NO
Integrity : achieve by S/MIME Cipher Key exchange : NO Prevention of replay attack : achieve by nonce
Concept of Design :Public/Private key based Authentication
The public key /private key of A : Pub_A/Pri_A The public key /private key of B : Pub_B/Pri_B A knows B’s public key Pub_B B knows A’s public key Pub_A
Nonce1
(response1,nonce2)
response1 = Pri_A (nonce1+1)
response2 =Pri_B(nonce2+1)
Verify response1by Pub_A
(response2)
Success
A B
Verify response2by Pub_B
Concept of Design : Certificate-based authentication (1/2)
Only CA’s public key has to be known.
NCTU
DB
CA_NCTU
SIP proxy1
SIP proxy2
UAC
Cr_Proxy1
Pub_CA_NCTU
Cr_Proxy2
Pub_CA_NCTU
Cr_UAC
Pub_CA_NCTU
INVITE
Authenticate required(Cr_Proxy2, nonce1)
(Cr_UAC, response1,nonce2)
Verify Cr_Proxy2by Pub_CA_NCTU=> Get Pub_Proxy2
response1 = Pri_UAC (nonce1+1) Verify Cr_UAC
by Pub_CA_NCTU=> Get Pub_UAC
response2 =Pri_Proxy2(nonce2+1)
Verify response1by Pub_UAC
(response2)
INVITE
UAC SIP proxy 2
Verify response2by Pub_Proxy2
Roaming agreement
NCTU
DB
CA_NCTU
SIP proxy1
SIP proxy2
NTU
DB
CA_NTU
SIP proxy4
SIP proxy3
UAC
Cr_Proxy1
Pub_CA_NCTU
Cr_Proxy2
Pub_CA_NCTU
Cr_UAC
Pub_CA_NCTU
Cr_Proxy4
Pub_CA_NTU
Cr_Proxy3
Pub_CA_NTU
Concept of Design : Certificate-based authentication (2/2)
Roaming agreement
NCTU
DB
CA_NCTU
SIP proxy1
SIP proxy2
NTU
DB
CA_NTU
SIP proxy4
SIP proxy3
UAC
Cr_Proxy1
Pub_CA_NCTU
Cr_Proxy2
Pub_CA_NCTU
Cr_UAC
Pub_CA_NCTU
Cr_Proxy4
Pub_CA_NTU
Cr_Proxy3
Pub_CA_NTU
Cr_CA_NTUCr_CA_NCTU
Cr_CA_NTU
Cr_CA_NTU
Cr_CA_NCTU
Cr_CA_NCTU
Pub_CA_NTU
Pub_CA_NTU
Pub_CA_NCTU
Pub_CA_NCTU
Concept of Design : Certificate-based authentication (2/2)
INVITE
Authenticate required(Cr_CA_NTU,Cr_Proxy4, nonce1)
(Cr_UAC, response1,nonce2)
Verify Cr_Proxy4by Pub_CA_NTU=> Get Pub_Proxy4
response1 = Pri_UAC (nonce1+1)
Verify Cr_UACby Pub_CA_NCTU=> Get Pub_UAC
response2 =Pri_Proxy4(nonce2+1)
Verify response1by Pub_UAC
(response2)
INVITE
UAC SIP proxy 4
Verify Cr_CA_NTUby Pub_CA_NCTU=> Get Pub_CA_NTU
Verify response2by Pub_Proxy4
Examine the Requirements Authentication
Mutual Authentication : YES Key Distribution : base on Certificate verification Roaming agreement : solved by PKI architecture
Integrity : S/MIME Cipher Key exchange : can be achieved by
public key & private key system Prevention of replay attack : achieve by nonce
New type of Headers have to be specified.
Concept of Design:Examine the requirements
The EndThe End
Authentication ProcedureINVITE
407 Proxy-Authentication RequiredProxy-Authenticate(nonce1)
ACK
INVITEProxy-Authorization (nonce1, response1)
response1 =F(nonce1,secret1)
INVITEINVITE
401 UnauthorizedWWW-Authenticate(nonce2)
Verifyresponse1
401401
ACKACK
ACKINVITE
Authorization (nonce2, response2)
INVITE
response2 =F(nonce2,secret2)
Verifyresponse2
INVITEAuthorization (nonce2, response2)
180 ringing180
180200
200
200 OK
ACKACK
ACK
UASSIP ProxySIP ProxyUAC
S/MIME 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 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
Content-Type: application/sdp v=0 o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com s=- t=0 0 c=IN IP4 pc33.atlanta.com m=audio 3456 RTP/AVP 0 1 3 99 a=rtpmap:0 PCMU/8000
SIP Header Privacy and Integrity using S/MIME : Tunneling 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 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: 568
--boundary42 Content-Type: message/sip
INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com; branch=z9hG4bKnashds8 To: Bob <bob@biloxi.com> From: Alice <alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 147
v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
--boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756
--boundary42-
SIP Header Privacy and Integrity using S/MIME : Tunneling 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: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:pc33.atlanta.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=boundary42 Content-Length: 568
--boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: 231
********************************************************* * Content-Type: message/sip * * INVITE sip:bob@biloxi.com SIP/2.0 * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * To: Bob <bob@biloxi.com> * From: Alice <alice@atlanta.com>;tag=1928301774 * Call-ID: a84b4c76e66710 * CSeq: 314159 INVITE * Max-Forwards: 70 * Date: Thu, 21 Feb 2002 13:02:03 GMT * Contact: <sip:alice@pc33.atlanta.com>
* Content-Type: application/sdp * v=0 * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * s=Session SDP * t=0 0 * c=IN IP4 pc33.atlanta.com * m=audio 3456 RTP/AVP 0 1 3 99 * a=rtpmap:0 PCMU/8000 **********************************************
Trusted network