On Wed, 2009-11-04 at 14:38 -0500, Dale Worley wrote: > The 3 applications everyone talks about are: > > - ITSP (sipXbridge to ITSP) > > - "federated" systems (sipXproxy to another proxy) > > - phones (remote and local) > > The first two can use manually configured certificates.
> But for phones, > we need to manage the certificates automatically, I think. I am > assuming that each phone should have an individual certificate, and we > need to be able to (implicitly or explicitly) invalidate certificates > that are compromised. There is also a bootstrap problem: How do we get > the certificate into the phone in the first place? The bootstrap problem has no general solution. You can't create a secure channel between two parties without already having a secure channel on which to exchange the security information for the new one. > Fortunately, we can generate individual certificates automatically. If we generate phone certs (which I don't actually think we need to do - see below), then we can also verify that a phone is using the certificate that we generated for it. I suspect, however, that many parties who care about things at this level will want to use certs from CAs other than ours. There is a lot of complexity to managing certs in devices, especially devices with very limited user interfaces and when trying to support multiple vendors, so it's worth looking at the difference between having a certificate in the device and not having one. Essentially, that difference is that you can authenticate that the device has the private key that goes with that certificate - that's it. You can't authenticate that it's the same device - anyone who cracks the phone open (physically or logically) and extracts the key can authenticate using the certificate and pretend to be that device. By itself, a phone certificate does not add anything to authenticating the user unless the phone stores the private key in encrypted form and requires the user to log in with a password that is the key with which to decrypt it (in which case you've changed the easiest attack from stealing the private key to stealing the password and the key). It's important to note that you do NOT need a certificate in the phones in order to get confidentiality protection (encryption) for your SIP signaling. Only the server side of a TLS connection (the end that accepts an offered connection) is required to have a certificate. Getting that mode to work correctly does require some extra logic in the phone (it has to keep a connection up to the server). There's an internet draft on using TLS connections in both directions that we should be factoring into our plans: http://www.ietf.org/id/draft-ietf-sip-connect-reuse-14.txt _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
