Identity in SIP (and in-band) STIR BoF Berlin, DE 7/30/2013.

Slides:



Advertisements
Similar presentations
Rfc4474bis-01 IETF 89 (London) STIR WG Jon & Cullen.
Advertisements

Authentication in SIP Jon Peterson NeuStar, Inc Internet2 Member Meeting Los Angeles, CA - Nov 2002.
STIR Credentials IETF 88 (Vancouver) Wednesday Session Jon & Hadriel.
STIR Secure Telephone Identity. Context and drivers STIR Working Group Charter Problem Statement Threats Status of work Related work and links Introduction.
Network Isolation Using Group Policy and IPSec Paula Kiernan Senior Consultant Ward Solutions.
September 19, 2006speermint interim1 VoIP Threats and Attacks Alan Johnston.
Requirements for Resource Priority Mechanisms for the Session Initiation Protocol draft-ietf-ieprep-sip-reqs-01 Henning Schulzrinne Columbia University.
Internet Protocol Security (IPSec)
August 13-14, 2002 Washington, DC Gary Richenaker Chair ENUM Forum
1 SIP WG meeting 73rd IETF - Minneapolis, MN, USA November, 2008 Return Routability Check draft-kuthan-sip-derive-00 Jiri
SIP Authorization Framework Use Cases Rifaat Shekh-Yusef, Jon Peterson IETF 91, SIPCore WG Honolulu, Hawaii, USA November 13,
DTMF & Universal User Key Input Skip Cave InterVoice-Brite Inc.
Voice over Internet Services and Privacy. Agenda Problem Description Scope Recommendations.
1 NGN Issues - Numbering and Addressing Peter Darling ACIF NGN FOG No. 3.
Architectural Considerations for GEOPRIV/ECRIT Presentation given by Hannes Tschofenig.
B2BUA – A New Type of SIP Server Name: Stephen Cipolli Title: System Architect Date: Feb. 12, 2004.
Web Services Security Standards Overview for the Non-Specialist Hal Lockhart Office of the CTO BEA Systems.
STIR Charter (discussion) STIR BoF Berlin, DE 7/30/2013.
Secure Credential Manager Claes Nilsson - Sony Ericsson
Chapter 21 Distributed System Security Copyright © 2008.
Lecture 27 Page 1 Advanced Network Security Routing Security Advanced Network Security Peter Reiher August, 2014.
Credentials Roadmap STIR WG IETF 90 (Toronto) Sean Turner
1January 2006Richard Stastny Developments around Infrastucture ENUM and their relevance on NGNs Workshop on NGN Interconnection and Numbering TRIS – TISPAN.
Security Issues in Control, Management and Routing Protocols M.Baltatu, A.Lioy, F.Maino, D.Mazzocchi Computer and Network Security Group Politecnico di.
Certificate Credentials STIR WG IETF 91 (Honolulu) Sean Jon.
November 2005IETF64 - ECRIT1 Emergency Service Identifiers draft-ietf-sipping-sos-01 draft-schulzrinne-sipping-service-01 Henning Schulzrinne Columbia.
7/6/20061 Speermint Use Case for Cable IETF 66 Yiu L. Lee JULY 2006.
IETF63 - enum WG1 ENUM validation architecture & friends Alex Mayrhofer enum.at / 3.4.e164.arpa Bernie Höneisen SWITCH.
STIR Problem Statement IETF 88 (Vancouver) Tuesday Session Jon Peterson.
1 SPEERMINT Use Cases for Cable IETF 66 Montreal 11 JULY 2006 Presented by Yiu L. Lee.
Peering: A Minimalist Approach Rohan Mahy IETF 66 — Speermint WG.
1 IETF 72 SIP WG meeting SIP Identity issues John Elwell et alia.
Rfc4474bis-01 IETF 90 (Toronto) STIR WG Jon. First principles (yet again) Separating the work into two buckets: 1) Signaling – What fields are signed,
1 IETF 88 (Vancouver) November 6, 2013 Cullen Jennings V3.
STIR In-Band Signature Transport draft-kaplan-stir-ikes-out-00 Hadriel Kaplan.
Implications of Trust Relationships for NSIS Signaling (draft-tschofenig-nsis-casp-midcom.txt) Authors: Hannes Tschofenig Henning Schulzrinne.
RFC3261 (Almost) Robert Sparks. SIPiT 10 2 Status of the New SIP RFC Passed IETF Last Call In the RFC Editor queue Author’s 48 hours review imminent IMPORTANT:
Rfc4474bis-03 IETF 92 (Texas) STIR WG Jon. First principles (yet again) Separating the work into two buckets: 1) Signaling – What fields are signed, signer/verifier.
ENUM WG mini-BOF Setting the Stage Richard Shockey IETF 60 San Diego.
Ch 6: DNSSEC and Beyond Updated DNSSEC Objectives of DNSSEC Data origin authentication – Assurance that the requested data came from the genuine.
User Authentication  fundamental security building block basis of access control & user accountability  is the process of verifying an identity claimed.
Enumservice VOID draft-stastny-enum-void-00 Richard Stastny Lawrence Conroy IETF60 San Diego.
Call Completion using BFCP draft-roach-sipping-callcomp-bfcp IETF 67 – San Diego November 7, 2006.
1 Public Key Infrastructure Rocky K. C. Chang 6 March 2007.
RPSEC WG Issues with Routing Protocols security mechanisms Vishwas Manral, SiNett Russ White, Cisco Sue Hares, Next Hop IETF 63, Paris, France.
1 End-to-middle Security in SIP Kumiko Ono NTT Corporation March 1, 2004 draft-ietf-sipping-e2m-sec-reqs-01.txt draft-ono-sipping-end2middle-security-01.txt.
K. Salah1 Security Protocols in the Internet IPSec.
Lecture 18 Page 1 CS 236 Online Advanced Research Issues In Security: Securing Key Internet Technologies CS 236 On-Line MS Program Networks and Systems.
Lecture 10 Page 1 CS 236 Online Encryption and Network Security Cryptography is widely used to protect networks Relies on encryption algorithms and protocols.
Telephone Related Queries (TeRQ) draft-peterson-terq-00.
Telephone Related Queries (TeRQ)
End-to-middle Security in SIP
draft-rescorla-fallback-01
STI Interworking with SIP-PBXs
sip-identity-04 Added new response codes for various conditions
Encryption and Network Security
STIR WG / IETF 94 Yokohama, Nov 2015 Jon
Chris Wendt, David Hancock (Comcast)
Proposed ATIS Standard for Signing of SIP RPH
Verstat Related Best Practices
Jean-François Mulé CableLabs
RFC PASSporT Construction 6.2 Verifier Behavior
RFC PASSporT Construction 6.2 Verifier Behavior
RFC PASSporT Construction 6.2 Verifier Behavior
IETF 101 (London) STIR WG Mar2018
Change Proposals for SHAKEN Documents
RFC Verifier Behavior Step 4: Check the Freshness of Date
IPNNI SHAKEN Enterprise Models: LEMON TWIST
STIR / SHAKEN for 911 use of SHAKEN 8/7/2019
draft-ietf-stir-oob-02 Out of Band
Presentation transcript:

Identity in SIP (and in-band) STIR BoF Berlin, DE 7/30/2013

In-band precedents RFC3325 (short-term identity) – Advantages: deployable, deployed! – Disadvantages: requires trusted network, and… Impersonation thrives in existing trusted networks RFC4474 (long-term identity) – Advantages: Great for SIP URIs and RFC3261 compliance – Disadvantages: doesn’t play well with telephone numbers, much of the world isn’t RFC3261-compliant Many subsequent attempts to do better – Alternative signature scopes, tokens, etc. – VIPR notably tried to solve identity and a host of related problems

Components of an in-band solution A field to carry a signature over various headers in a SIP request – e.g., RFC4474 Identity header – Intended to provide a cryptographic assertion of authority over the From header field and other components of the message: Prevent replay by cut-and-paste attacker – Problem: many elements are changed by SIP intermediaries, which to choose? A way to acquire and validate the public key of the signer over those headers – e.g., the RFC4474 Identity-Info header Includes carrying the key in band – Problem: Many viable approaches, which to allow/disallow? RF4474 vaguely assumed public ENUM would have certs for numbers in the DNS

In-band STIR Logical Architecture Inter- Mediary Inter- Mediary PBX Endpoint PBX Endpoint User Endpoint User Endpoint User Endpoint User Endpoint User Endpoint Logical Authority Logical Authority Unsigned Requests Inter- Mediary Inter- Mediary PBX Endpoint PBX Endpoint User Endpoint User Endpoint User Endpoint User Endpoint Credential Provisioning Credential Validation Signed Requests

Revisiting what? Which RFC4474 assumptions failed? SIP deployments remained focused on PSTN interworking – IP-PSTN, PSTN-IP, IP-PSTN-IP, PSTN-IP-PSTN – Telephone numbers are therefore the primary identifier of SIP – No story for certs in e164.arpa ever took hold Lack of unmediated end-to-end SIP signaling – Deployments are highly mediated, intermediary agency is not bounded – Mediated for various reasons, from NAT to interop to security Policy enforcement of many kinds – Many calls still drop to the PSTN due to lack of IP routes RFC4474 solved for SIP requests in general – Assumed a world with MESSAGEs and NOTIFYs, not just INVITEs

Rescoping to the Problem For threats like robocalling and voic hacking, man-in-the-middle attacks are not a real concern How best to separate the replay-protection goal from the man-in-the-middle prevention goal? – Not an entirely clean split – Scope the To/From protection to just the telephone number, when a telephone number is present Domain or other parameters not helpful Canonicalization required, a non-trivial problem – Necessarily include some kind of timestamp (Date) – Handle body protection separately, when you need it Ultimately, possible to create some kind of linked two-layer signature

Limits of in-band It’s in-band – At best, this addresses the SIP-to-SIP use case Maybe, e.g. IKES, with something else in the middle – Not going to help with SIP-to-PSTN, PSTN-to-PSTN – But we believe IP-to-IP is the future, right? So we still need in-band Will SIP networks allow it? – Difficult to anticipate what will survive deployments No guarantees are possible – Needs to change existing service behavior Intermediaries need to do new things