1. SIP Greg Nelson Duc Pham

2. SIP Introduction Application-layer (signaling) control protocol for initiating a session among users Application-layer (signaling) control protocol for initiating a session among users Registrations, invitations, acceptations, and disconnections Registrations, invitations, acceptations, and disconnections

3. SIP Diagram ABProxy (Registrar local services) ……. Register 200 Ok Register 200 Ok Invite 100 Trying Invite 100 Trying Invite 180 Ringing 200 Ok Ack Media Session Bye 200 Ok

4. SIP Acronyms UAC: a user agent client making requests. UAC: a user agent client making requests. UAS: a user agent server responding to the requests (the roles of UAC and UAS are logical entities) UAS: a user agent server responding to the requests (the roles of UAC and UAS are logical entities) SS: flexibly preferred to any middle servers: registrar, proxy servers SS: flexibly preferred to any middle servers: registrar, proxy servers

5. SIP Vulnerabilities Proxy Impersonation Proxy Impersonation Message Tampering Message Tampering Session Teardown Session Teardown Spoofed BYEs Spoofed BYEs Denial of Service Denial of Service Malformed packets Malformed packets REGISTER and INVITE flooding REGISTER and INVITE flooding Registration Hijacking Registration Hijacking

6. SIP Security Registration hijacking Registration hijacking Authenticate originators of requests Authenticate originators of requests Proxy impersonation Proxy impersonation Authenticate servers Authenticate servers Message tampering Message tampering Secure body and certain headers end-to-end Secure body and certain headers end-to-end Session teardown Session teardown Authenticate sender of BYE Authenticate sender of BYE Confidentiality so attacker can’t learn To, From tags Confidentiality so attacker can’t learn To, From tags Denial of Service Denial of Service Authenticate and authorize registrations Authenticate and authorize registrations

7. Objectives Use AVISPA to model basic protocol. Use AVISPA to model basic protocol. Model SIP URI registration and look for registration hijack attacks. Model SIP URI registration and look for registration hijack attacks. Model interdomain session setup and look for message tampering and proxy impersonation attacks. Model interdomain session setup and look for message tampering and proxy impersonation attacks. Add proxy-to-proxy authentication and secrecy (TLS) to model. Add proxy-to-proxy authentication and secrecy (TLS) to model. Discuss other vulnerabilities that we weren’t able to model. Discuss other vulnerabilities that we weren’t able to model.

8. SIP Model (1) Simplified message formats: REGISTER REGISTER OK OK INVITE INVITE BYE BYE ACK ACK

9. SIP Model (2) Register: Register: UAC -> SS: {sipregister.Ns} SS -> UAC: {sipok} Invite, connect, bye: Invite, connect, bye: UAC -> SS: {sipinvite.UAC.UAS.{Ni}} SS -> UAS: {sipinvite.UAC.UAS.SS.{Ni}} UAS -> SS: {sipok.UAS.UAC.SS.{Nj}} SS -> UAC: {sipok.UAS.UAC.{Nj}} UAC -> UAS: {sipack.UAC.UAS} UAC -> UAS: {sipbye.UAS.UAC} UAS -> UAC: {sipok.UAC.UAS}

10. Discussion --- Authentication Server Authentication: using TLS: server offers a certificate to the UA, preventing proxy impersonating Server Authentication: using TLS: server offers a certificate to the UA, preventing proxy impersonating User Authentication: using HTTP digest: server challenges a user with a 401 Proxy Authentication, preventing registration hijacking User Authentication: using HTTP digest: server challenges a user with a 401 Proxy Authentication, preventing registration hijacking

11. Discussion --- Interdomain Authentication Trust relationship needed: client-server, server- server Trust relationship needed: client-server, server- server UAC SS UAS UAC SS Evil UAC SS SS Evil More infrastructures required for absolute interdomain authentication: signature verifications, voice recognitions More infrastructures required for absolute interdomain authentication: signature verifications, voice recognitions

12. Discussion --- Message Secrecy Mechanisms that rely on existence of end-user certificates are seriously limited (S/MIME). Mechanisms that rely on existence of end-user certificates are seriously limited (S/MIME). May use self-signed certificates May use self-signed certificates Susceptible to obvious MITM attack, but… Susceptible to obvious MITM attack, but… Attacker can only exploit on initial key exchange. Attacker can only exploit on initial key exchange. Difficult for attacker to remain in path of all future dialogs. Difficult for attacker to remain in path of all future dialogs. Same vulnerability in SSH => key fingerprints. Same vulnerability in SSH => key fingerprints. For VoIP, users could read off key fingerprint. For VoIP, users could read off key fingerprint. Or, use preconfigured certificates when there is an established trust between all SIP entities. Or, use preconfigured certificates when there is an established trust between all SIP entities.

13. Discussion --- DoS Attacks Floods of messages directed at proxies can lock up resources on the server. Floods of messages directed at proxies can lock up resources on the server. UAs and proxies should challenge questionable requests. UAs and proxies should challenge questionable requests. Mutual authentication of proxies (TLS) Mutual authentication of proxies (TLS) Reduces potential for intermediaries to introduce falsified requests or responses. Reduces potential for intermediaries to introduce falsified requests or responses. Harder for attackers to make innocent SIP nodes into agents of amplification. Harder for attackers to make innocent SIP nodes into agents of amplification.

14. Conclusions AVISPA is easy to use, but difficult to model something besides secrecy and authentication, such as DoS. AVISPA is easy to use, but difficult to model something besides secrecy and authentication, such as DoS. Registration hijacks are easy to prevent with server authentication (TLS). Registration hijacks are easy to prevent with server authentication (TLS). TLS prevents MITM, but does nothing if proxy is evil; need end-to-end encryption. TLS prevents MITM, but does nothing if proxy is evil; need end-to-end encryption. Simple protocol becomes very complex when addressing vulnerabilities. Simple protocol becomes very complex when addressing vulnerabilities.