Re: [stir] New draft draft-rosenberg-stir-callback-00

["Peterson, Jon" <[e-mail]>]

Well nice of you to join us here, finally!

So broadly, we have long needed some kind of proof-of-possession test for calling party numbers to help expedite STIR deployment. We've sketched out various approaches like doing that with SMS return-routability tests (see section 4.2 of draft-ietf-acme-telephone, say), and having a SIP-level way to do such a test definitely seems like a valid approach. I don't recall that we've considered a kind of "callback on first use" (COFU?) approach to this before. It has some good properties.

I guess the one comment I'd make about the overall direction though is that up until now, I've been envisioning staging these proof-of-possession tests within ACME. In other words, propping up a boulder implementation that would challenge with some kind of routability test to establish effective proof of control of a number in order to get you an 8226 individual-TN cert. Practically speaking, that ACME challenge could use stir-callback pretty much as your draft describes it. I don't think deploying an ACME CA to do this faces anything like the practical hurdles that faced public ENUM, say. It's something anyone could do tomorrow (if the necessary elements supported stir-callback tomorrow).

I suppose, speaking to the example in the stir-callback Overview section, that requiring Bob's call agent to maintain a "validation cache" that maps calling party numbers to public keys serves a similar purpose to having a CA that effectively attests that calling party numbers are associated with certificates. The question is whether that mapping database is better staged in one or more ACME-style CAs or in every call agent that participates in this architecture. Off the top of my head it doesn't seem easier to be from an implementation or deployment standpoint to stage this in the call agents. And doing this in a way that gives you an 8226 cert - even a self-signed one - would I think have a more realistic incremental deployment path toward the long-term STIR architecture.

So definitely support having this capability, I think there are choices to make about exactly how to approach it, and we should discuss in London. We need this, so I'm happy to see some energy around it.

Jon Peterson
Neustar, Inc.

From: stir <[e-mail]<mailto:[e-mail]>> on behalf of Jonathan Rosenberg <[e-mail]<mailto:[e-mail]>>
Date: Thursday, March 1, 2018 at 6:14 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [stir] New draft draft-rosenberg-stir-callback-00

Hey all - been a while :)

Cullen and I wrote up a concept for using STIR with self-signed or domain based certs, and then handling number validation with an in-band callback. We think its a promising approach to accelerate STIR deployments, since it allows them to happen without the cert infrastructure being in place.

https://www.ietf.org/id/draft-rosenberg-stir-callback-00.txt

Comments welcome.

-Jonathan R.

--
Jonathan Rosenberg, Ph.D.
[e-mail]<mailto:[e-mail]>
http://www.jdrosen.net