90 likes | 203 Views
SIP Security. Michael Thomas Mat@cisco.com. Status. First Cut of Requirements Draft draft-thomas-sip-sec-reqt-00.txt Will be basis going forward Design team being formed Should complete soon Drafts which can meet all of the requirements will not be short term exercise
E N D
SIP Security Michael Thomas Mat@cisco.com
Status • First Cut of Requirements Draft • draft-thomas-sip-sec-reqt-00.txt • Will be basis going forward • Design team being formed • Should complete soon • Drafts which can meet all of the requirements will not be short term exercise • Prioritization of requirements needed
bis Strawman • We have enough understanding of the current requirements that some prioritization can probably be made for bis • If we are to move bis along, the baseline must be fairly uncontroversial, be based on existing protocols, and address enough threats so that it is acceptable to IESG • But… there is also a strong desire for additional mechanisms and support for different authentication backends
Two Paths • Choose a limited base set of protections offered by bis with the guarantee that we will have a standards track SIP security framework • We’re relatively close to coming to consensus here • Existing hop-by-hop crypto and legacy http mechanisms • Resolve future proofing questions • Open up discussions about what ought to be in bis baseline • No consensus • Many competing agendas • Many competing authentication mechanisms
My Suggestion • In order to get bis to move forward soon, we have very few options • If we don’t care about moving forward, then an endless discussion is probably appropriate • The only real question is whether an unambitious baseline will pass muster • My sense is that it solves the most serious problems that SIP deployments currently face • Other mechanisms are oriented at enabling different authentication deployment scenarios; no single answer here, so it’s difficult to pick one anyway.
The bis Baseline • Two principle threats: • Various attacks from non call participants • Theft of service attacks at a remote proxy/gateway • Full Message Crypto Solves 1st Threat • IPsec, TLS, App layer • HTTP Digest provides 2nd
Transport Options • IPsec + Provides keying mechanism + TCP/SCTP/UDP friendly • Credential fetching API currently lacking • TLS + Provides keying mechanism + Good credential binding mechanism • No support for UDP; SCTP still being worked on • App Layer + Most flexible since it would be SIP-custom • No keying mechanism • No off the shelf solution which fits requirements
UAC->Middle/UAS • HTTP Digest currently in Bis + Widely implemented • No concept of mutual authentication • No facility for multiple challenges • Key distribution undefined • Hacked on Digest + Quick and dirty - Unproven; not widely reviewed by right people • Side effects questionable - Not clear whether benefits fits into the 80/20 rule • New SIP-secure + Should solve these kinds of problems systematically - Needs to be fully fleshed out