SIP Greg Nelson Duc Pham

SIP Greg Nelson Duc Pham

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

SIP Diagram A . Register 200 Ok Proxy Proxy (Registrar local services) Invite 100 Trying 180 Ringing 200 Ok . Invite 100 Trying 180 Ringing 200 Ok Ack Media Session Bye 200 Ok . Register 200 Ok Invite 180 Ringing 200 Ok B

SIP Acronyms 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) SS: flexibly preferred to any middle servers: registrar, proxy servers

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

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

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

SIP Model (1) Simplified message formats: REGISTER Domain To From Contact(device) OK To From INVITE To From Via Content BYE To From ACK To From

SIP Model (2) Register: UAC - SS: {sipregister.Ns} SS - UAC: {sipok} 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}

Discussion --Authentication 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

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

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

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

Conclusions 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). TLS prevents MITM, but does nothing if proxy is evil; need end-to-end encryption. Simple protocol becomes very complex when addressing vulnerabilities.