Category Archives: Standards

SIPIt 20 shows the very clear need for SIP security interoperability

Last week, SIPit chair Robert Sparks posted the results of a SIP interoperability survey to the IETF SIP mailing list coming out of the recent SIPit 20 event held in April. For those not familiar with “SIPit” events, they are week-long events sponsored by the SIP Forum held twice a year where vendors bring together their SIP products to test interoperability between their various products and implementations. This particular event, the 20th, was hosted by Alcatel Lucent in Antwerp, Belgium. 67 vendor teams participated, of which 59 completed the web-based survey that generated this data.

The full results of the survey make for interesting reading, but I thought I’d pull out some of the security-related items. First up, SIPS (aka TLS-encrypted SIP):

There was a lot of (understandable) confusion about what to do with sips:. Most implementations that could handle TLS are not yet trying to handle sips:. The few that did try to do something sane with sips: are watching the discussion on the SIP mailing list. In any case, there was not a set of implementors present who felt sips was sufficiently specified and would be unhappy if the definition changed. I also didn’t find anyone who felt an existing deployment would suffer from any change to the definition.

Next up, NAT traversal and STUN/TURN/ICE:

When asked about STUN support, the client implementations replied:
8% I implement all the client requirements of draft-ietf-behave- rfc3489bis
6% I implement some, but not all, of the client requirements of draft-ietf-behave-rfc3498bis
4% I implement all of the client requirements of RFC3489
14% I implement some, but not all, of the client requirements of RFC3489
60% I do not implement STUN as a client
8% Other

There were several STUN servers and at least two TURN servers. We had more TURN clients this time, and successfully exercised TURN. Three implementations claimed support for ICE, but no interoperability was reported (I suspect there were versioning issues that couldn’t be overcome in the time-scale of the event). There was one ice-tcp implementation present.

And the big one of most interest to me personally (and with my emphasis added):

There were 9 SRTP endpoints (down from 12 at the last event). Only 4 of those used sdes.
Interoperability after key exchange was lower than at SIPit 19.

There was only one RTP over DTLS implementation present.

Anyone doubt that we still have a good bit of work to do??

As I mentioned, the full survey results are definitely worth a read if you are interested in SIP interoperability.

Blue Box Podcast #55: IP phone vulnerabilities, ZRTP and IETF, Skype security, listener comments and more

Blue Box Podcast #55 was posted today with a look at recent vulnerabilities in IP phones, VoIP security news and a feature section about the IETF meeting and the discussion there around SRTP key exchange, ZRTP, etc.  A great amount of listener comments and much more.  See the detailed show notes for a full description of what was discussed.

Blue Box #54 – new VoIP security tools list, teleworker FUD, Phil Zimmermann, ETel feedback, SPIT, IETF

Blue Box Podcast #54 was posted about a week ago but with travel I didn’t cross-post it here… in this show, Jonathan and I talked a good bit about the new VoIP security tools list released by VOIPSA, the IETF meeting in Prague, Phil Zimmerman and ZRT, SPIT, the ETel conference and also talked a good bit about some articles circulating around about “how VoIP shouldn’t be used for teleworkers because of security”. Detailed show notes and links are available over on the Blue Box website.

SRTP key exchange – minutes of the IETF RTPSEC meeting now posted

As noted earlier, there was an “RTPSEC BOF” session at the IETF 68 meeting last week in Prague. Minutes of the RTPSEC meeting have now been posted, which give a sense of how the discussion went. I’ll provide my own commentary in a separate post (and probably this week’s Blue Box podcast)… for now, I’ll point you to the minutes.

Please note, too, that we welcome guest bloggers here, so if someone who was there is interested in providing their own view on the meeting, drop me a note. We’re always glad to provide a forum for folks to post about VoIP security.

Next week – perhaps the most important IETF meeting about VoIP security in a long time – how will we do SRTP key exchange?

Next week in Prague, at the 68th IETF meeting, there will be a great many meetings of importance to people concerned about VoIP security, but perhaps none more important than the RTPSEC BOF about SRTP key exchange on Monday, March 19th. As readers and listeners know, one of the key missing standards right now is how vendors can exchange encryption keys for SRTP.

It sounds (and is) geeky, but here’s the impact to the market. Right now, if you buy an IP-PBX system and IP phones from Vendor A, but you want t also buy some SIP phones from Vendor B, there is currently no agreed-upon way for Vendor A and Vendor B’s phones to send secure voice from one phone to the other. Within Vendor A’s IP-PBX and phones, SRTP can be used – and if you were to buy a full system from Vendor B, SRTP could be used entirely there… but there is no agreed-upon way to let Vendor B’s phones work with Vendor A’s phones for SRTP.

Back at IETF 66 in July 2006 there were 11 or 13 proposals (which we covered in Blue Box Podcast #22) but the fields been narrowed now to basically three: DTLS, ZRTP (Phil Zimmermann’s proposal) and a new version of MIKEY. Dan Wing is leading another face-to-face session next week in Prague where the intent is to try to narrow this even further and see if we can’t all agree on a common standard for how to do SRTP key exchange.

IF YOU HAVE COMMENTS OR OPINIONS, NOW is the time to make them! If you can’t get to Prague, you can still join the RTPSEC mailing list or read the Internet Drafts and send comments in to the authors. Please read the drafts and do provide comments… if we are to see secure voice interoperability between SIP phones, this meeting and the discussion therein is extremely important. Please make your opinion heard.

New IETF proposal on secure call recording with SIP and SRTP

Dan Wing just released a new Internet Draft called “Disclosing Secure RTP (SRTP) Session Keys with a SIP Event Package” that merits attention and consideration. As Jonathan and I have discussed on Blue Box and as has been discussed in the VOIPSEC mailing list from time to time, there are situations where you want both the secure encryption of all voice and also the ability to record calls. However, right now this is difficult to do in any “standard” way in the world of SIP, and this new proposal is one view of how that situation might be solved. Dan is looking for feedback (and his address can be found in the document) and this document will no doubt be discussed at the upcoming IETF meeting in Prague in mid-March.

Blue Box Podcast #44: SIP attack tools, VoIP security news, IETF, patents, ZRTP, Skype security, Asterisk war dialling, voice biometrics, listener comments and more

Blue Box Podcast #44 is now available for download. In this show, we cover the new SIP attack tools released by Mark Collier and Dave Endler, talk about the IETF meeting, ZRTP and Phil Zimmermann’s patent disclosure, Skype security issues, a war dialling script for Asterisk, listener comments and much more. Feedback is, as always, welcome.

Minutes available for RTPSEC BOF in Montreal on SRTP key exchange

Dan Wing announced that draft minutes of the RTPSEC BOF in Montreal are now available.  This session at the IETF 66 meeting was to discuss the various ways of securing the key exhange for SRTP and to see if we could move the requirements along and reduce the 13 or so proposals down to a more workable number.  As noted in the minutes, there was significant progress made on deciding various requirements.  The next step will be to see what comes out in terms of refined proposals to address those requirements.

Beyond the Bitpipe

I recently installed BT Communicator, which is British Telecom’s answer to Skype.  Like Skype it allows free calls (PC to PC) and offers the capability to break out onto the PSTN to call anyone anywhere, for a fee.  Being naturally curious, I fired up Wireshark and captured some of the activity on the line, and I was delighted to discover that it’s using our old friends SIP and RTP to signal and carry the calls.  In contrast, if you capture Skype traffic, you can’t figure out what’s happening unless you put an awful lot of research into it.

Are BT offering unique value with their service?  I think so: firstly the billing backs into the same BT billing system, and ends up on my phone bill, where Skype operate a pay-as-you-go system that needs charging via card etc.  One less thing to worry about with BT.  Secondly, unlike Skype, BT are embracing open standards, but still with an eye on security (the service uses Proxy Authentication to secure the calls, but no crypto yet).  Skype consider their softphone to be an important part of their service offering, and won’t open up the protocol to other clients.  As I see it, most of the Skype value is in the sheer number of customers that use the service, and I imagine Ebay also saw it this way, but this is a topic for another day.  BT, on the other hand, are looking further out to the open standards world, where it will be an advantage to be SIP-compatible.  Perhaps this is already architected to slot right in to their IMS backbone, 21CN.  One final advantage is that there are actually people out there that don’t use the Internet much, and don’t know about Skype.  So BT are actually using their marketing money to tell these people that they can call their friends for free using Communicator.   Of course they are cannibalizing their own call revenue, but perhaps they see the bigger picture, that like Skype, this can be used to pull through all kinds of other revenue generating services.

I like this approach to business better than that of companies like Shanghai Telecom and China Telecom, who reportedly have bought software technology to detect and block Skype traffic.  Presumably, they will also be blocking SIP, since this is technically much less difficult.  The thinking behind this is that if people aren’t calling with Skype, then they have to pick up the legacy phone.  This kind of thinking, “I don’t make any money out of this; can I block it?” is just the kind of blinkered approach that leads to telco lobbying in the net neutrality debate in the US.  Companies like AT&T would like to get paid twice, once by the Skypes and Googles, and then again by their telco customers.  Of course we’d all like to get paid twice, but most of us don’t have the political clout to make it happen. 

BT have not always been the most dynamic company, but I imagine that if they can learn something about business from Skype, then all large telcos stand a chance.  So come on guys, stop wringing your hands and worrying about becoming the bitpipe, and get out there and innovate.

66th IETF Meeting starts tomorrow in Montreal – streaming audio and video available for remote listening

FYI, the 66th IETF meeting starts tomorrow and the good news is that courtesy of the University of Oregon, you can listen/watch the sessions remotely. As noted in the IETF meeting agenda, there are a good number of sessions relating to security. One of special interest may be the RTPSEC BOF at 5:40pm (Eastern US) Monday night, where the topic of discussion will be all the various ways to securely exchange encryption keys for Secure RTP. The sessions will be streamed live, but will apparently also be available in an archive after the sessions are over.

UPDATE: There is also Jabber-based IM group chat available.  If you already have a Jabber IM account somewhere (like Jabber.org), you can join a group chat room by connecting to the Jabber server “jabber.ietf.org” and then giving the working group name as the room name.  For instance, the chat room for the ENUM session I am in right now is “enum@jabber.ietf.org”.  Just another way to stay up with what is going on at the meetings for those interested.