[Free-RTC] QR codes, mobile SIP provisioning, TLS certs

[Daniel Pocock]

On 08/07/16 14:46, Saúl Ibarra Corretgé wrote:
> On 07/07/16 18:37, Daniel Pocock wrote:
>>
>>
>> Hi all,
>>
>> One of the GSoC students, Pranav[1], has had a focus on Java, Android
>> and account provisioning
>>
>> He has already done some work on a library[2] to allow mobile apps to
>> quickly deploy accounts from any ITSP
>>
>> One of the next things under discussion is how to make mobile app SIP
>> account provisioning with QR codes.
>>
>> Every vendor of deskphones has their own provisioning system, they are
>> all quite different.  Some are quite effective, e.g. the way Polycom
>> puts certificates in every phone to avoid the risk of exposing
>> credentials during provisioning or subsequent updates.
>>
>> Pranav can potentially create:
>>
>> a) a JAR for inclusion in apps like Lumicall and CSipSimple,
>> Conversations (XMPP) and Jitsi (on both mobile and desktop)
>>
>> b) a REST service running in Apache Tomcat that interacts with the
>> client JAR
>>
>> The question is, how should the workflow be structured?
>>
>> Has anybody seen anything like this already, either for SIP, XMPP or
>> other protocols like email accounts?
>>
>> What should be in the QR-code, for example, should it just contain a URL
>> or parameters for generating a certificate request?
>>
>> Once the app starts talking to the URL, what data should be exchanged?
>>
>> Does the phone need to prompt the user for any data, e.g.a PIN, or can
>> it all be automatic?
>>
>> Once the account is initially set up, how will changes to the settings
>> be deployed?  Should the phone periodically poll the REST server and
>> accept any changes automatically, or should there be a workflow for the
>> user to confirm any changes?
>>
>> I'm thinking that this facility could work for both per-account settings
>> and maybe per-phone settings, but in the latter case we need to make
>> sure it can deal with conflicts and let the user override anything.
>>
>> Regards,
>>
>> Daniel
>>
>>
> 
> I followed the thread, good talk! Here is a completely different
> approach: make the information in the QR code insecure by design.
> 
> Not sure if this is the case, but I got inspired by how WhastApp does
> it. The QR code needs to be displayed somewhere. Where is that? If
> that's a website where the user already logged in, the dynamically
> generated QR code could have some plaintext data with the user account
> credentials.
> 
> Now, if we also want to provision the TLS cert, then passing a URL
> pointing to it and the expected fingerprint should work (right?).
> 

To clarify the reason I mentioned QR codes in the first place, it is
only for user convenience.  Although humans can't read the QR codes,
they are not "secure", just obscure

I don't see any reason we can't let the user see the provisioning URL
and credentials and enter them manually, but the more convenient we make
it the more people will use it.