draft-rescorla-fallback-01 STIR WG Seoul Nov 2016

Thread Necromancy Been a long time… Charter: “the in-band mechanism must be sent to the IESG for approval and publication prior to the out-of-band mechanism.” Voila (that’s rfc4474bis) We’ve been very busy with the in-band work However, tried to make sure we didn’t close any doors on out-of-band Use certificates in common, say We do have an out-of-band charter milestone even Though we missed the date by a little

Do we still need it? Fixing end-to-end IP-IP is not enough Which original RFC4474 assumptions failed? SIP deployments mostly involve PSTN interworking Thus still largely concerned with telephone numbers Some IP-IP, but much IP-PSTN, PSTN-IP-PSTN, even PSTN-IP Much problematic robocalling uses IP-PSTN We also see IP-PSTN-IP When a gateway has no IP route and drops to the PSTN, which eventually routes back to IP Fixing end-to-end IP-IP is not enough

Limits of in-band RFC4474bis It’s in-band – end-to-end IP-IP At best, it addresses the SIP-to-SIP use case Not going to help with SIP-to-PSTN, PSTN-to-PSTN We did in-band first because existing deployments need it Like the IPNNI, now the SHAKEN profile Some IP-IP deployments may not pass Identity e2e Difficult to anticipate what will survive administrative boundaries PAI-based deployments should leak across trust boundaries And some existing deployments might just block Identity As they block all new headers; especially B2BUAs

PASSporT and out-of-band PASSporT bridges the gap between in-band and out-of-band An object format that could be carried by SIP, or another protocol Some interest in adapting to Jingle (XMPP) Potentially in WebRTC as well PASSporT could also be stored for retrieval at a service Out-of-band here refers to architectures where that happens somewhere along the signaling path Depends on Internet enabled endpoints and/or gateways

Some use cases

Basic STIR Out of Band CPS Call Placement Service Store PASSporT Retrieve PASSporT PSTN Smart Phone Smart Phone POTS Call Smart Phones are not just mobile phones, and not just end-user devices

Obvious Questions Okay, how does the originating side know where to find a CPS? How do we make sure the terminating side comes to exactly the same conclusion? Need a service discovery mechanism A few initial ideas in the draft now And how do we manage the risk that someone other than the called party will fetch it? Significant privacy concerns These are the things its time to work on

Components of an OOB solution A service for storing and retrieving PASSporT objects Or a “Call Placement Service”, CPS A discovery mechanism for the CPS Needed both for storing and retrieving This creates a rendez-vous function, effectively Smart phones (not necessarily mobile) Internet enabled: could be an IP PBX or whatever A robust story about privacy

Another Case: IP-PSTN Gateways CPS Store PASSporT Retrieve PASSporT PSTN SIP/STIR GW SIP UA Smart Phone POTS Call

… and its many cousins We can show a parallel flow for PSTN-IP Again, where the PSTN endpoint is a smart phone that creates a PASSporT Or even some local agent does it on behalf of the endpoint These use cases can look a lot like tunneling We can’t count on SS7 to carry a PASSporT Could carry an indication that the original call was signed… but cryptographic assurance is superior Some use cases where in-band and out-of-band are other used Out-of-band beomes the “fallback”

IP-PSTN-IP even? Sure! CPS Store PASSporT Retrieve PASSporT PSTN SIP/STIR SIP/STIR GW GW SIP UA SIP UA POTS Call

Well, let’s not get carried away How do we know a GW is authorized to store it? Should a GW need a pre-association with the CPS? Most likely, the authority to store is really invested in the PASSporT itself Multiple entities may be authorized to sign for the same “orig” in PASSporT And how do we know a GW is authorized to retrieve it? Same questions, really Can’t predict where calls will land, so hard to encrypt for the target But good CPS design could help…

CPS Design Questions Store PASSporTs under the originating or terminating identity? What is the key of the lookup? Currently: terminating side queries for the originating number Or store under something hashed instead? Hash of originating TN and terminating TN Still, possible for an adversary to compute all values offline Maybe add timestamp of some kind? Expensive hash? Also, implement polling prevention for single targets

Next Steps Already on the charter, targeting WG item adoption Though not just this second Given RFC4474bis/PASSporT/certs pass the IESG Maybe have some virtual interim early next year to discuss further Appreciate comments/thoughts Crucial to have a good PSTN story for STIR I think something along these lines could help