90 likes | 175 Views
SIP Security. Henning Schulzrinne Columbia University. Priority security requirements. REGISTER protection authentication and integrity confidentiality (harder) DOS prevention for non-authenticated requests
E N D
SIP Security Henning Schulzrinne Columbia University
Priority security requirements • REGISTER protection • authentication and integrity • confidentiality (harder) • DOS prevention for non-authenticated requests • authenticated requests already prevent DOS and amplification, but not realistic for INVITE • End-to-end authentication • for random clients (very hard) • for repeat visitors • End-to-end message confidentiality 52nd IETF SLC
Re-using existing technology • Options include: • Enhanced C/R (digest) authentication • IP DOS prevention • S/MIME • Shared secret via common infrastructure • Transport-layer security • Pointless to argue about which we don’t need – all have different strengths and weaknesses • Does not preclude new mechanisms 52nd IETF SLC
Enhanced digest • Protect selectable subset of headers • Minimal extension to Digest • Ease of implementation – trivial addition to existing Digest • No infrastructure • No privacy • REGISTER 52nd IETF SLC
IP-reachability security • DOSA prevention: Simply ensure that INVITE comes from valid IP address • Inherent in Digest, but not likely to be common for INVITE • Require guessing of large random number • Must be stateless in server • Options: • NULL authentication • Special Digest qop value • Does not prevent use as reflector 52nd IETF SLC
S/MIME • Existing solution, existing code • Treat SIP message like email attachment: • Content-Type: message/sip ??? • Requires client certs? • What if ssh-style security is sufficient (same host as last time, but can’t prevent MiM for first attempt) 52nd IETF SLC
Shared secret • Avoid SIP-PGP mistakes: • canonical form • header ordering • special headers • SIP part is easy once infrastructure is assumed (CMS?) 52nd IETF SLC
Automating future trust • Authentication not very helpful for random callers as long as identities are cheap – yes, it’s indeed slimebag@coolmail.com • Want to ensure subsequent call is from same person • D-H works except for active MiM – ssh has the same problem! 52nd IETF SLC
Transport-layer security • TLS works for server authentication • Is this indeed sip.example.com? • Works well iff • number of peers small (some evidence in DNS measurements – Zipf distribution) • setup delay for new peers reasonable (need measurements!) 52nd IETF SLC