Federation Security: Transitive Trust
In my last post, I poked fun at telephony voicemail as a less-helpful feature that will ultimately be replaced by presence. Another feature that was a presence precursor was Caller-ID, which allows you to identify who is calling as an aid to ‘screening’ your calls and thereby letting the telemarketers to go to the ‘black hole’ of voicemail. Of course, if you value your own privacy (or if you are a telemarketer), Caller-ID can not only be spoofed or bypassed, ‘Blocked Caller-ID’ is actually an ‘upsell’ feature provided by the phone company. This is all the more comical when the phone company also offers an ‘anonymous caller rejection’ feature which allows someone to block calls with Blocked Caller-ID!
But I digress. In another post, I briefly alluded to the features that NextPlane implements to protect your privacy and yet ensure that ‘callers’ are who they say they are; and I thought it worthwhile to expand on that a little more and explain how the UC era will be different from the telephony era in this respect.
You might be wondering how you can trust a federated communication that is coming from second party, via a third party service (i.e. NextPlane) and why UC ‘caller id’ is reliable. Various UC systems that we interoperate with, as well as our federation service, are based on SIP and XMPP. Both of these are public protocols that could theoretically be manipulated by miscreants. However, the security of these communication technologies is ensured by powerful encryption technology and the public key infrastructure (PKI). The key to understanding this is in a simple math principle that you probably remember from grade school:
If A = B, and B = C, then A = C
This, you will recall, is the transitive property of equality. UC technologies use a ‘transitive trust model’ where:
If A trusts B, and B trusts C, then A trusts C
This is to say that if company A trusts NextPlane (and vice versa) and Nextplane trusts company C (and vice versa) then company A can trust company C. So far, so good; but how is this trust established? Each UC deployer has to purchase a unique digital certificate from a Certificate Authority. NextPlane transitively trusts its customers because it trusts the Certificate Authority. The NextPlane service tests each certificate with the Certificate Authority every time a message is sent to or from a NextPlane customer and thereby has 100% confidence that domain is in fact that of company A.
A theoretical attack on this scheme is for a spoofer to intercept the message, copy the certificate, and use it to misrepresent its identity. However, a combination of encryption (which itself requires a digital key) and certificate-based authentication prevent interception and spoofing. With XMPP, a further safeguard is that NextPlane never accepts an XMPP message from a customer without first ‘dialing back’ to a known IP address to ensure that the sender is who they say they are.
Despite the fact that telephony networks were closed and proprietary, fraud was commonplace and ridiculously easy: everything from ‘fat finger dialing’ to ‘slamming’. The Internet is more open and scams abound, but that has caused the standards bodies to develop robust security schemes to facilitate things like online banking and UC. A side effect of these security schemes is the concept of non-repudiation: it is impossible to deny that a message emanated from a user in a given domain if the recipient (in this case, NextPlane) has logged the certificate and encryption key. So, while we can’t guarantee that you will never get an unwanted call from a federation partner, we can guarantee the identity of that ‘caller’ and, as discussed in my last post, you always have the option of not accepting it.