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

[Daniel Pocock]

On 08/07/16 11:45, Olle E. Johansson wrote:
> 
>> On 08 Jul 2016, at 11:42, Daniel Pocock <daniel at pocock.pro> wrote:
>>
>>
>>
>> On 08/07/16 10:21, Olle E. Johansson wrote:
>>>
>>>> On 08 Jul 2016, at 10:15, Daniel Pocock <daniel at pocock.pro> wrote:
>>>>
>>>>
>>>>
>>>> On 08/07/16 10:03, Olle E. Johansson wrote:
>>>>>
>>>>>> On 08 Jul 2016, at 10:02, Daniel Pocock <daniel at pocock.pro> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/07/16 09:12, Olle E. Johansson wrote:
>>>>>>>
>>>>>>>> On 07 Jul 2016, at 19:37, Daniel Pocock <daniel at 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-certificate-on-android-device
>>
>> 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