Category: Security

Can We Create A "Secure Caller ID" For VoIP? (Join Tomorrow’s STIR BOF To Learn More)

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

You can also join the Jabber chat room at:

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?


Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."


If you found this post interesting or useful, please consider either:


Video: IP-Spoofing / Routing Best Practices Panel at RIPE 66

Can we stop the spoofing of IP addresses? Is the problem serious enough to warrant high-level attention? Are there best practices for routing that the larger community should be engaging in? What are the real challenges with stopping IP spoofing? These are the questions addressed in a recent post by our colleague Andrei Robachevsky, “Can we stop IP-spoofing in the Internet?” and a corresponding panel at the RIPE 66 event in Dublin, Ireland, in mid-May.

If you are are interested in this topic of how we increase the security and resiliency of routing, we highly recommend both reading Andrei’s article and listening to the panel presentation from Dublin. (Click on the image below to go to the RIPE66 page where you can view the video.)

ripe66-video

Slides are also available but they were primarily used to frame the introduction to the panel. The real content is in the panel discussion itself.

Please visit our new Routing Resiliency/Security area to learn more about this general topic of how to make the Internet’s routing infrastructure more resilient and secure.

 

TONIGHT – Live Webcast of "WordPress Security: Fact & Fiction"

Wordpress orgInterested in WordPress security and making your site as secure as possible? Tonight, June 18, 2013, at 7:00pm US Eastern time (about 2 hours from now), I just learned that tonight's WordPress NYC meetup will be livestreamed. The description sounds great:
D.K. Smith will present a comprehensive range of WordPress security best practices, including: Methods for repairing a hacked site; “Multiple Layers of Security” techniques that keep your site secure. There will also be a preliminary presentation by Austin Gunter on the distinctions between managed, shared and dedicated hosting.

Unfortunately I won't be able to attend live, but I will look to watch the archive of the event.

If any of you are able to watch this live, it will stream out of:

http://www.livestream.com/internetsocietychapters

Looking forward to listening to it...


If you found this post interesting or useful, please consider either:


IPv6hackers Group To Meet In Berlin on July 28, 2013

IPv6 hackersInterested in IPv6 security? Want to see presentations by people working in the field? If so the members of the “ipv6hackers” mailing list are planning to hold their first face-to-face meeting in Berlin on July 28, 2013, the Sunday prior to IETF 87 in Berlin, Germany.  From the announcement email:

We’re planning to have our first in-person meeting on July 28th, 2013, in Berlin (most likely in the afternoon, between lunch and the IETF welcome reception). The venue would be either the IETF venue (InterContinental Berlin), or some nearby hotel/room (to be confirmed soon).

We’re planning to have some presentations (which MUST be accompanied with code :-) ), and might also have an IPv6 mini-hackathon (i.e., work on code, test implementations, try stuff).

Fernando Gont has asked people who are interested in attending to complete a short survey so that he can know how many people are planning to attend.

If you are interested in IPv6 security, I have found the IPv6 hackers mailing list to be a useful list to monitor as a good number of IPv6 security researchers do participate in the list.  You can see from the archives some of the topics that are discussed. It is open for anyone to subscribe.  There is also a LinkedIn group but as Fernando notes he created the group to help people connect on LinkedIn not as a discussion forum – discussion happens on the email list.

Video: My Discussion of DNSSEC and DANE with VoIP / SIP on The VUC

What role could DNSSEC potentially play to help better secure voice-over-IP (VoIP)? How could the DANE protocol help provide a stronger level of security to SSL/TLS certificates used in VoIP? What VoIP software out there right now works with DNSSEC?

Back on May 3, 2013, I participated in a VoIP Users Conference (VUC) call on precisely these questions. In the call that went for close to 90 minutes I outlined what DNSSEC and DANE are all about, how they work in a web browser world and how they could potentially work in a world of VoIP with SIP. We also discussed the current support for DNSSEC in the Jitsi softphone and the Kamailio SIP server. There was also a healthy question and answer period where we went off on different tangents. I referenced a presentation I made at SIPNOC 2013 and the slides for that presentation as well as other resources are available from the Deploy360 DNSSEC and VoIP page.

It was a great call and the video is available on YouTube:

If you want to just listen to the audio, you can play or download it from the VUC episode page.


If you found this post interesting or useful, please consider either:


Packet Pushers Healthy Paranoia Podcast: IPv6 Security Smackdown

Packet Pushers podcast logoInterested in IPv6 security? Back in October 2012, the Packet Pushers podcast had a great show on the topic called “Healthy Paranoia Show 4:IPv6 Security Smackdown!” Guests included many of the people we’ve routinely interacted with about IPv6 at events and on mailing lists:

  • Fernando Gont, security researcher
  • Eric Vyncke, Cisco Distinguished Consulting Engineer and author
  • Joe Klein, security researcher
  • TJ Evans, IPv6 instructor and engineer
  • Jim Small, Sr. Consultant – Network/Security Architecture and Engineering, CDW
  • Scott Hogg, Cisco Press author and Director of Technology Solutions for RMv6TF

The show runs about 90 minutes and is well worth a listen!

At SIPNOC 2013 This Week Talking About VoIP And IPv6, DNSSEC … and Security, Of Course

Sipnoc 2013 logoOne of the conferences I've found most interesting each year is the SIP Network Operators Conference (SIPNOC) produced by the SIP Forum, a nonprofit industry association. Part of my interest is that it is only an educational conference, i.e. there's no massive exhibit floor or anything... it's all about education. It also brings together pretty much all the major players in the "IP communications" space - certainly within North America but also from around the world.

I'll be there this week in Herndon, Virginia, talking about how VoIP can work over IPv6 and how DNSSEC can make VoIP more secure. The sessions I am directly involved with include:

  • Panel Discussion: Anatomy of a VoIP DMZ
  • VoIP Security BOF
  • Panel Discussion:  IPv6 and SIP - Myth or Reality?
  • Who Are You Really Calling? How DNSSEC Can Help

There are quite a range of other topics on the SIPNOC 2013 agenda, including a number of other talks related to security.  

It should be quite a good show and I'm very much looking forward to it.  I'm particularly looking forward to my "DNSSEC and VoIP" talk on Thursday as that is a topic I've not presented on before... but I think there is some quite valuable potential about using DNSSEC with VoIP.

If you are there at SIPNOC this week, please do say hello!

P.S. While SIPNOC is not being livestreamed, you may find some people tweeting using the hashtag #SIPNOC.


If you found this post interesting or useful, please consider either:


U.S. DHS Warns of TDoS (Telephony Denial of Service) Attacks

DHS TDOS AlertThe U.S. Department of Homeland Security recently issued a bulletin titled “TDoS Attacks on Public Safety Communications” and while it was “Law Enforcement Use Sensitive/For Official Use Only” a copy was obtained by Brian Krebs who wrote about it on his site and also published the DHS bulletin publicly.

This resulted in a small flurry of related articles that Mark Collier listed on his VoIP security blog. Most of the articles, unfortunately somewhat predictably, seem to be rehashes of Brian Krebs’ post and/or the DHS bulletin.  However, the point is definitely solid – these are real attacks that are happening on call centers out there, including those operated by emergency services organizations.  No one wants to be on the receiving end of hundreds (or thousands) of phone calls clogging up your call center and making it unusable for regular business.

The connection to VoIP is that made by Brian Krebs in his article:

According to a recent report from SecureLogix, a company that sells security services to call centers, free IP-PBX software such as Asterisk, as well as computer-based call generation tools and easy-to-access SIP services, are greatly lowering the barrier-to-entry for voice network attackers.

This is the key point.  VoIP systems make these kind of attacks much easier to create.  Anyone can take one of the various free VoIP servers and create a script that will generate a crazy number of phone calls.  And of course the Caller-ID can be easily spoofed using the same servers.  I’m sure there are already scripts out there that automate all of this for would-be attackers.

The challenge is then finding either a VoIP service provider (or “ITSP” or “SIP Service Provider”) who will let the attacker send out phone calls to the PSTN – or to find victims that allow incoming SIP connections (which means that attacks could come from any Internet connection).  Or to find components of the SIP signaling infrastructure that have weak (or no) authentication and through which an attacker can send calls.  For example, SIP gateways that allow incoming SIP calls with minimal (or easily spoofable) authentication.

It’s not necessarily easy to do, but VoIP systems do make it easier than it was in the past, largely because the attackers can obtain a degree of anonymity through masking their source, and also because of the automation of the calling possible through the systems.

Defending against a TDoS is not the easiest, particularly when the attackers can use spoofed Caller IDs to hide their origin.  Here is a place where VoIP actually helps because if the calls are coming in over IP, firewalls and other network monitoring tools can be used to recognize patterns and potentially identify and block sources of the attacks.  There are companies such as SecureLogix (whose CTO is Mark Collier, whom I linked to earlier) who do sell products and services to help address these threats. As we increasingly move to IP-based communications there will no doubt be many more companies and service providers offering such services.

We as an industry do need to do what we can to help people understand both the threat posed by these attacks, and also the mitigations and possible solutions.

In the meantime, expect more people to be talking about this issue due to this DHS bulletin and the surrounding attention in the media.

What do you think?  What should be done within the VoIP vendor/organization community?  What are good steps to promote to defend against TDoS attacks?

“Introduction To DNSSEC” Animated Videos Uploaded To YouTube

With the buzz over Google’s news about DNSSEC yesterday, we’ve seen a large surge of visitors to our DNSSEC-related resources and in the midst of that someone pointed out that the excellent introduction to DNSSEC video from Shinkuro, Inc., was no longer available on YouTube. Given that we work well with the Shinkuro team, we reached out to them and found out that while they maintain a copy of the video on their site, they had not been responsible for the YouTube version.  With their permission, we have now uploaded the video to our Deploy360 YouTube channel and can make it available for embedding and viewing:

The silent animated video was created back in 2006 but continues to be an excellent illustration of how the DNSSEC process works and the threats it protects again.  Thanks again to Shinkuro for making the video available.

As we note on our resource page about the video, there is also a second version that doesn’t include the text narration on the right side that some of you may find useful if you want to show a video about DNSSEC and provide your own narration.  (In fact… it might be an interesting exercise to take this second video and create versions with voice-overs in a number of different languages – if you do that and create a version, let us know and we’ll look at linking to your video.)

 

Deploy360@IETF86: Day 4 – IPv6, DNSSEC and Routing, Oh, My!

IETF LogoDay 4 of the 86th meeting of the Internet Engineering Task Force (IETF)  hits all of our Deploy360 topics – IPv6, DNSSEC and Routing Resiliency/Security.

General information about participating remotely can be found on the Remote Participation page as well as the IETF86 agenda – specific info for the groups we are following is included below.


0900-1130 Thursday, March 14

Homenet – Caribbean 3
This working group focuses on the evolving networking technology within and among relatively small “residential home” networks.

Interface to the Routing System (I2RS) – Caribbean 5
This is a new working group meeting for the first time that is seeking to define a publicly documented interface into the Internet’s routing system for applications to use. The best way to understand this new group would be to read draft-atlas-i2rs-problem-statement.


1300-1500 Thursday, March 14

Port Control Protocol (PCP) – Caribbean 6

The PCP working group is back again looking at how to enable communication from applications across middleboxes such as Network Address Translation (NAT) devices and firewalls for both IPv4 and IPv6.

Two other groups also may be of interest during this time block:


1510-1710 Thursday, March 14

Dynamic Host Configuration (dhc) – Caribbean 1
The DHC working group looks at DHCP and aspects of dynamically configuring IP addresses, both for IPv4 and IPv6, although the focus these days is on DHCPv6.

Operational Security  (opsec) – Caribbean 3
The OPSEC working group looks at the operational security concerns of IP networks. In this meeting there are 3 drafts focused on the security of IPv6 networks.


1730-1830 Thursday, March 14

Dynamic Host Configuration (dhc) – Caribbean 1
The DHC working group will continue to meet during this timeslot. Information is above.

DNS Operations  (DNSOP) – Caribbean 4
The DNSOP Working Group focuses on operational aspects of the Domain Name System and at this session has multiple drafts relating to DNSSEC.


1900-2100 Bits-N-Bites

This reception / networking time in Grand Sierra D should be an interesting chance to look at new technology from a number of sponsors.

2000-?  Alternative PKI Side Meeting, Boca 4

For those people interested in authentication and the public key infrastructure (PKI) aspects of the Web, there will be an “Alternative PKI Models Side Meeting” in room Boca 4, the IAB office, to talk about the requirements, goals and the design assumptions for a Web PKI.  Given our interest in DNSSEC and DANE, I (Dan) will be in this meeting to participate.

And after all of that… we’ll be trying to figure out how to get some food.  :-)

P.S. For a broader view of the Internet Society’s interest in IETF 86 beyond that of just the topics we cover here at Deploy360, please see our “Rough Guide to IETF 86′s Hot Topics“.


NEW! Listen to this post (and please follow Deploy360 on SoundCloud if you use that service):