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

[Pranav Jain]

Hi,
In this case wont there be lot of changes that provider needs to done at
their end? They need to make a whole mechanism for one time URL.
On 11-Jul-2016 9:09 PM, "Scott Griepentrog" <sgriepentrog at digium.com> wrote:

> 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
>
> _______________________________________________
> Free-RTC mailing list
> Free-RTC at lists.fsfe.org
> https://lists.fsfe.org/mailman/listinfo/free-rtc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fsfe.org/pipermail/free-rtc/attachments/20160711/16feabbb/attachment-0001.html>