SIP Security Henning Schulzrinne Columbia University
6/25/ nd IETF SLC 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
6/25/ nd 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
6/25/ nd IETF SLC Enhanced digest Protect selectable subset of headers Minimal extension to Digest J Ease of implementation – trivial addition to existing Digest J No infrastructure L No privacy è REGISTER
6/25/ nd 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
6/25/ nd IETF SLC S/MIME Existing solution, existing code Treat SIP message like 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)
6/25/ nd IETF SLC Shared secret Avoid SIP-PGP mistakes: canonical form header ordering special headers SIP part is easy once infrastructure is assumed (CMS?)
6/25/ nd IETF SLC Automating future trust Authentication not very helpful for random callers as long as identities are cheap – yes, it’s indeed Want to ensure subsequent call is from same person D-H works except for active MiM – ssh has the same problem!
6/25/ nd 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!)