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

[Scott Griepentrog]

A better way to keep the complexity of the QR code down would be to encode
only a single-use HTTPS URL, which then returns a json blob with all of the
needed parameters.  For security reasons, you don't want the password in
any plaintext format.  And to protect the URL, it can only be obtained
once, after which is is invalidated.  If a new URL is needed because the
first attempt didn't work, force the backend to regenerate a new password
so that the old one (which might have gotten leaked) is invalid.

On Fri, Jul 8, 2016 at 11:14 AM, Daniel-Constantin Mierla <miconda at gmail.com
> wrote:

> Hello,
>
>
> On 07/07/16 19: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
> >
> >
> > 1.
> https://wiki.debian.org/SummerOfCode2016/StudentApplications/PranavJain
> > 2. https://github.com/pranavjain/AndroidSIPEnroller
> from the past experience, the providers that build their softphone go
> for a https/rest provisioning system, with attributes embedded in the
> app. Sometimes, even they push the client certificate signed by their CA.
>
> For generic sip phone apps, I think zoiper (free version, but not open
> source, though) has a qrcode provisioning feature, but never got to try
> it myself.
>
> The thing is that qrcode cannot store lots of info and there are tons of
> setting options for each of those sip/xmpp/etc. apps.
>
> So I think the qrcode reader app for provisioning the phone should
> consider dealing with data providing:
>
> accountid=uniquevalue
> option1=value1
> ...
> optionN=valueN
>
> Where only 'accountid' is a reserved key and needs to be in all qrcodes.
> Then there can be only one or many options.
>
> The provider can have many qrcodes next to their provisioning
> instructions on a web page (e.g., to set domain, outbound proxy, ...).
>
> Introducing all options by hand can be a real pain for mobile devices.
> For openrcs.com (free pure sip service running kamailio), the decision
> was to generate the sip passwords by the server and display them (only
> on demand and each time generating a new one, when asked to show the
> password) via the web portal, in the user account page. Later I added
> the display of a qrcode containing the password, just for reading it
> with a generic qr code app, to copy&paste in the sip app.
>
> Getting to stage where many mobile apps will be able to provision
> themselves from a well nown qrcode data format would be indeed useful!
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> http://www.asipto.com - http://www.kamailio.org
> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>
> _______________________________________________
> Free-RTC mailing list
> Free-RTC at lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/free-rtc
>



-- 
[image: Digium logo]
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090
Check us out at: http://digium.com · http://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/free-rtc/attachments/20160711/6f1bd262/attachment.html>