Re: [stir] Draft posted

Questions:

1) Section 4.1 says: "The question of how an entity is determined to have control of a given number is out of scope for this document."
But that's like half the problem, if not more.  Are you saying this fallback mechanism would re-use whatever authentication mechanism/model the in-band one uses?  I.e., it could come from some database of public keys, or some certificate signing authority chain, and either way it doesn't matter to this fallback thing?

I have a hard time understanding how that would work in practice.  The in-band mechanism's number authentication/credentials model has so far assumed private/public keys... and that realistically an end user/device wouldn't have a private key for the phone number, but that its service provider or carrier would instead.  So if the fallback is meant for carriers to be the "Alice" and "Bob", I would understand how the same authentication/credentials model of in-band could possibly work for fallback.  But not if Alice and Bob are truly end users/devices.

On the other hand, for a real end-user model, I could see very different authentication models used: for example by having Alice sign up for the CPS service, and part of the sign-up process being the CPS calling her phone or sending her an SMS, using the claimed phone number, and giving her some cookie to type/copy into the CPS' app to complete the sign-up process authentication.  After that her app would always have credentials to claim her number, though it would have to be renewed once a year or something.  And of course Bob would have to do the same, since you can't let just anyone ask if Alice is calling Bob.

But those types of details make a big difference for this stuff.  As I've said before on the list: if the fallback is meant for end-user smartphones/apps, I grok that something we define could be useful in *theory*; but I don't think we know if something we define would be useful in *practice*.  I don't know if it is actually needed by those who would deploy it, nor if it works the way they'd want it to work, with the features they'd want it to have.  In short: we don't have the right people involved in STIR for that type of thing.  We'd just be shooting in the dark.

2) How would this thing handle call-forwarding scenarios?  It's a nasty, ugly, brutal scenario even for in-band to handle... but I think it has to be handled. (as much as I wish it were otherwise)

3) What are the odds that Alice and Bob happen to use the same CPS service?  Would there be only one?  Who decides who that Highlander CPS is?  If it follows a "Federated Verification Service" model instead, where everyone uses their favorite CPS service and the CPS providers interconnect some way, why isn't that just either re-creating the PSTN using a protocol other than SIP, or even just re-creating the existing SIP service provider interconnection world of today?  I mean that's essentially what section 5.5 proposes to do.  Or worse, it's like VIPR all over again, without learning the lessons from VIPR's failure.  Maybe the fallback thing could be called "VIPRedux"? ;)

-hadriel

On Jul 14, 2013, at 8:37 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> Folks,
> 
> I have posted a -00 draft that provides a high-level description of
> how one might do STIR out-of-band mode. I've deliberately
> cut out a lot of the detail of the previous version and/or
> relegated it to a separate section. The idea here is to look
> at the big picture.
> 
> http://tools.ietf.org/html/draft-rescorla-stir-fallback-00
> 
> -Ekr
> 
> 
> 
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir