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
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
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.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
/O
On 08/07/16 09:12, Olle E. Johansson wrote:
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
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.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote:
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
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.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
/O
On 08/07/16 10:03, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote:
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
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.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
There you mentioned the fingerprint of the server cert, I was referring to the root that will sign the client cert. It may be the same root signing the server cert too.
On 08 Jul 2016, at 10:15, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:03, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote:
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
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.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
There you mentioned the fingerprint of the server cert, I was referring to the root that will sign the client cert. It may be the same root signing the server cert too.
If you want to simplify the PKI, you simply say “here’s a fingerprint of the cert the server will give you”. Then you don’t need to validate any server chain.
If you say “here’s the fingerprint of the root CA you will have to have in your repo and will be used to sign the intermedia cert given to you, which is used to sign the server cert” you make life a bit more complex, since you have to have a way to distribute the root CA cert before you start provisioning.
If you want both, you may add a variable saying what you do - like in DNSsec.
Maybe we should also look into exchange of raw elliptic curve keys, saying “here’s the public key you will meet” to make life even more simple.
A third option, which I don’t prefer is to give a HTTPS url (using a well-known TLS cert assumed to be approved by all devices) where you can download the root CA cert. This is what SIP identity does. I think assuming all phones have one single CA will be wrong. Phones are not laptops. But it may work on mobile devices. Whether you can easily download a cert to the mobile device cert store remains unknown to me.
/O
On 08/07/16 10:21, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:15, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:03, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote:
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote:
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.
Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
There you mentioned the fingerprint of the server cert, I was referring to the root that will sign the client cert. It may be the same root signing the server cert too.
If you want to simplify the PKI, you simply say “here’s a fingerprint of the cert the server will give you”. Then you don’t need to validate any server chain.
If you say “here’s the fingerprint of the root CA you will have to have in your repo and will be used to sign the intermedia cert given to you, which is used to sign the server cert” you make life a bit more complex, since you have to have a way to distribute the root CA cert before you start provisioning.
If you want both, you may add a variable saying what you do - like in DNSsec.
Maybe we should also look into exchange of raw elliptic curve keys, saying “here’s the public key you will meet” to make life even more simple.
I think that allowing all these possibilities is reasonable, if the API is generic then different organizations can use it in different ways.
A third option, which I don’t prefer is to give a HTTPS url (using a well-known TLS cert assumed to be approved by all devices) where you can download the root CA cert. This is what SIP identity does. I think assuming all phones have one single CA will be wrong. Phones are not laptops. But it may work on mobile devices. Whether you can easily download a cert to the mobile device cert store remains unknown to me.
The initial target will be Android devices. Android's KeyChain API allows apps to install client certificates and root certificates and the Android OS is meant to prompt the user to confirm when this is happening. http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certifi...
Apps can also create their own key stores in the normal filesystem but these are slightly more vulnerable to manipulation and they can't be shared easily between multiple apps.
Regards,
Daniel
On 08 Jul 2016, at 11:42, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:21, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:15, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:03, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote:
> On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote: > > 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. Polycom’s system was broken because there was no secure way to validate their root ca. It was only available from a non-TLS site and wasn’t referred to in any printed documentation, not on promotional USB sticks or anything…
Good idea, poor implementation. If they made it available on a web site with HTTPS it would have been much easier to trust the CA.
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
There you mentioned the fingerprint of the server cert, I was referring to the root that will sign the client cert. It may be the same root signing the server cert too.
If you want to simplify the PKI, you simply say “here’s a fingerprint of the cert the server will give you”. Then you don’t need to validate any server chain.
If you say “here’s the fingerprint of the root CA you will have to have in your repo and will be used to sign the intermedia cert given to you, which is used to sign the server cert” you make life a bit more complex, since you have to have a way to distribute the root CA cert before you start provisioning.
If you want both, you may add a variable saying what you do - like in DNSsec.
Maybe we should also look into exchange of raw elliptic curve keys, saying “here’s the public key you will meet” to make life even more simple.
I think that allowing all these possibilities is reasonable, if the API is generic then different organizations can use it in different ways.
A third option, which I don’t prefer is to give a HTTPS url (using a well-known TLS cert assumed to be approved by all devices) where you can download the root CA cert. This is what SIP identity does. I think assuming all phones have one single CA will be wrong. Phones are not laptops. But it may work on mobile devices. Whether you can easily download a cert to the mobile device cert store remains unknown to me.
The initial target will be Android devices. Android's KeyChain API allows apps to install client certificates and root certificates and the Android OS is meant to prompt the user to confirm when this is happening. http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certifi...
Apps can also create their own key stores in the normal filesystem but these are slightly more vulnerable to manipulation and they can't be shared easily between multiple apps.
Adding a private CA in the generic key store as opposed to the app-only keystore seems a bit more open for bad stuff happening…
/O
On 08/07/16 11:45, Olle E. Johansson wrote:
On 08 Jul 2016, at 11:42, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:21, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:15, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 10:03, Olle E. Johansson wrote:
On 08 Jul 2016, at 10:02, Daniel Pocock daniel@pocock.pro wrote:
On 08/07/16 09:12, Olle E. Johansson wrote: > >> On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro wrote: >> >> 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. > Polycom’s system was broken because there was no secure way > to validate their root ca. It was only available from a non-TLS site > and wasn’t referred to in any printed documentation, not on promotional > USB sticks or anything… > > Good idea, poor implementation. If they made it available on a web > site with HTTPS it would have been much easier to trust the CA. >
For something like this, everybody who operates the provisioning system would be able to create their own CA. It may also work with public CAs (e.g. those who issue email certificates). Maybe we should include the root certificate or the CN and hash of the root certificate in the QR-code and then the provisioning client can verify it against the certificate that is eventually issued?
I think I suggested that in a follow-up email :-)
There you mentioned the fingerprint of the server cert, I was referring to the root that will sign the client cert. It may be the same root signing the server cert too.
If you want to simplify the PKI, you simply say “here’s a fingerprint of the cert the server will give you”. Then you don’t need to validate any server chain.
If you say “here’s the fingerprint of the root CA you will have to have in your repo and will be used to sign the intermedia cert given to you, which is used to sign the server cert” you make life a bit more complex, since you have to have a way to distribute the root CA cert before you start provisioning.
If you want both, you may add a variable saying what you do - like in DNSsec.
Maybe we should also look into exchange of raw elliptic curve keys, saying “here’s the public key you will meet” to make life even more simple.
I think that allowing all these possibilities is reasonable, if the API is generic then different organizations can use it in different ways.
A third option, which I don’t prefer is to give a HTTPS url (using a well-known TLS cert assumed to be approved by all devices) where you can download the root CA cert. This is what SIP identity does. I think assuming all phones have one single CA will be wrong. Phones are not laptops. But it may work on mobile devices. Whether you can easily download a cert to the mobile device cert store remains unknown to me.
The initial target will be Android devices. Android's KeyChain API allows apps to install client certificates and root certificates and the Android OS is meant to prompt the user to confirm when this is happening. http://stackoverflow.com/questions/4461360/how-to-install-trusted-ca-certifi...
Apps can also create their own key stores in the normal filesystem but these are slightly more vulnerable to manipulation and they can't be shared easily between multiple apps.
Adding a private CA in the generic key store as opposed to the app-only keystore seems a bit more open for bad stuff happening…
I've started a wiki about it:
https://wiki.debian.org/UnifiedCommunications/SoftphoneProvisioning
It would be useful if people could help add any of the following:
- examples of similar systems, either for RTC or other technologies like email
- examples of apps that should use it
- comments about device-level and account/line specific parameters and how we should name them
- help suggest how the client library should interact with the app, e.g. should it put everything into a Java Properties class, or should we create a proper bean class with methods like getPermittedCodecs(), getPassword(), ...
Regards,
Daniel
On 07 Jul 2016, at 19:37, Daniel Pocock daniel@pocock.pro 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.
I think this has to be targeted in many steps. Don’t bother with configuration file formats, it’s a dead end. Everyone wants to their own thing.
Focus on discovery - how do you discover the provisioning server? And what credentials do you need to attach to get your configuration? Just name them “provdata[x]” and not “user”, “secret” etc because you have no idea of what data one wants to send to the server. Make it *very* generic.
If you can attach a fingerprint of the expected TLS cert of the provisioning server I think that would be a step forward.
/O
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?).
Regards,
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.
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.
Agreed. I never meant to imply they would need to be obscured in any way.
So, the information we would encode could be:
- account URI - password - server / outbound proxy (optional) - TLS cert URL - TLS cert fingerprint
Anything else?
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
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
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@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
https://wiki.debian.org/SummerOfCode2016/StudentApplications/PranavJain
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@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/free-rtc
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@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@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
https://wiki.debian.org/SummerOfCode2016/StudentApplications/PranavJain
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@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@lists.fsfe.org https://lists.fsfe.org/mailman/listinfo/free-rtc