Speaking of Standards

The IETF announced today that the IAB, ISOC, MIT and W3C are jointly hosting a workshop at MIT on December 8 and 9 on the topic of Internet privacy. A website is up at:

http://www.iab.org/about/workshops/privacy/

And the announcement started out with this text:

The Internet Architecture Board (IAB), World Wide Web Consortium (W3C), Internet Society (ISOC) and Massachusetts Institute of Technology (MIT) will hold a joint Internet privacy workshop on 8 and 9 December 2010 at MIT, Cambridge, Massachusetts on the question:

“How Can Technology Help to Improve Privacy on the Internet?”

Information about who we are, what we own, what we have experienced, how we behave, where we are located, and how we can be reached are among the most personal pieces of information about us. This information is increasingly being made more easily available electronically via the Internet, often without the consent of the subject.

The question for the workshop therefore is: How can we ensure that architectures and technologies for the Internet, including the World Wide Web, are developed in ways that respects users‚ intentions about their privacy?

This workshop aims to explore the experience and approaches taken by developers of Internet including Web technology, when designing privacy into these protocols and architectures. Engineers know that many design considerations need to be taken into account when developing solutions. Balancing between the conflicting goals of openness, privacy, economics, and security is often difficult…

It sounds like a great event and if you are interested in participating, information is available on the event web site.

Given my background in security, I’ve been asked a number of times… why didn’t the IETF or someone just mandate ONE way to secure audio or video sent via RTP? After all, RTP by itself does not have any real security built-in and while Secure RTP (SRTP) is increasingly used, it’s not universal.

I’m obviously not alone in being asked this question, and Colin Perkins and Magnus Westerlund at the IETF wrote up an Internet-Draft that was recently approved to be an Informational RFC on just this topic:

Why RTP Does Not Mandate a Single Security Mechanism
http://tools.ietf.org/html/draft-ietf-avt-srtp-not-mandatory

From the introduction:

The Real-time Transport Protocol (RTP) [RFC3550] is widely used for voice over IP, Internet television, video conferencing, and various other real-time and streaming media applications. Despite this, the base RTP specification provides very limited options for media security, and defines no standard key exchange mechanism. Rather, a number of extensions are defined to provide confidentiality and authentication of RTP media streams and RTCP control messages, and to exchange security keys. This memo outlines why it is appropriate that multiple extension mechanisms are defined, rather than mandating a single security and keying mechanism.

The document goes on to list where RTP is use and issues with various security mechanisms (including SRTP). If you ever wondered why everyone doesn’t just use SRTP… this short document may be well worth the read.

As a “security guy“, I have been pleased to watch the emergence of the OAuth Working Group within the IETF and the work that is underway to create an actual IETF specification for OAuth. I haven’t had time to participate, but I’m glad to see that work going on.

If you aren’t aware of OAuth, it’s basically a way that you can authorize a application or service to interact with another application or service on your behalf without giving that first application or service your user ID and password for the second service or app.

For example, if you were a Twitter user in its earlier days, every time you wanted to use another application or web service with your Twitter account, you had to give that app or service your Twitter user ID and password. There’s a security issue here in that you are entrusting your credentials to some other company or application – and trusting that they won’t share those credentials. There’s also a configuration issue in that if you change your password you then have to go to all the other services and provide the updated info. Now, with OAuth support in Twitter, when you want to add a new service to interact with your Twitter account, you are prompted to login to your Twitter account and authorize or deny the access for the new service. The key point is that the new service or application never gets your Twitter credentials. (And as another example, OAuth is what our IMified service uses to allow an automated bot to interact with your Twitter account.)

Anyway, OAuth emerged out of the developer community and now there is work underway in the IETF to create official standard specifications to help in promoting OAuth implementation. As a first step, it was announced this week that OAuth 1.0 will be published as an Informational RFC. As noted in the announcement:

The OAuth protocol was originally created by a small community of web developers from a variety of websites and other Internet services, who wanted to solve the common problem of enabling delegated access to protected resources. The resulting OAuth protocol was stabilized at version 1.0 in October 2007, and revised in June 2009 (revision A) as

published at <http://oauth.net/core/1.0a>.

This specification provides an informational documentation of OAuth Core 1.0 Revision A, addressing several errata reported since that time,

as well as numerous editorial clarifications. While this specification is not an item of the IETF’s OAuth Working Group, which at the time of writing is working on an OAuth version that can be appropriate for publication on the standards track, it has been transferred to the IETF for change control by authors of the original work.

This first step will get a base level spec out so that people looking to implement OAuth will have an IETF specification they can use. The RFC hasn’t been published yet, but the draft that will be an RFC is here:

http://tools.ietf.org/html/draft-hammer-oauth

It’s good to see this work going on within the IETF and I look forward to seeing further work there. From my perspective, OAuth is a great step in helping secure connections betweens apps and services over the web… which is good for all of us as more and more moves into the cloud.

If you aren’t thinking about the security of your VoIP systems, you should be, because the tools to attack those systems keep getting better. Over on the Voice of VOIPSA blog, I recently wrote about the release of a new suite of security test tools that make some of the attacks now “point-and-click”.

For a variety of reasons, many of these attacks are against SIP or unencrypted RTP, so they are definitely good to understand.

P.S. Note that VOIPSA (VoIP Security Alliance) does have a lengthy list of VoIP security tools already… this new suite is just one more to be added to the list.

Technorati Tags: sip, sip security, voip, voip security, security, voipsa

So if we get to the point where we can truly “trust” the identity of the person calling us on the other end of a SIP connection, what will that look like to the end user? How will I know – easily – that I can trust that the “Caller ID” displayed on my IP phone is in fact who it says it is? Is there a “visual identifier” of some type that I could have on my IP phone (or softphone) that would clue me in? Kind of like the “lock” icon in web browsers that indicates a call is encrypted?

Those were the questions I was looking to address in a new Internet-Draft I submitted yesterday:

draft-york-sip-visual-identifier-trusted-identity-00

One of the things we focus on here at Voxeo is to ensure that the user experience is as simple and easy as possible. That’s why we rolled out our Designer tool a few years back. That’s why we spent a good amount of time looking to make Prophecy Log Search as simple to use as possible – and why we continue to improve it.

So in the discussions that have been going on within the IETF circles around the incredible need to nail down the ability to have “trusted identity” within communication based on SIP (which I wrote previously, one of the questions I’ve kept asking myself is “how will this appear to a regular end-user?” Based on some comments in the SIP mailing list the other day, I decided to write up this draft.

Feedback is welcome. I’ve already received the comments that I didn’t address the whole issue of PSTN interconnectivity, i.e. if it’s coming from a PSTN gateway, how do you deal with the fact that the Caller ID could have been spoofed on the PSTN side. I’m sure other comments will come in as well.

As I say in the draft, it’s not entirely clear to me that the IETF is the right place to have this discussion since ultimately it is about the user interface in vendor products… but at least it’s a place to start.

Technorati Tags: ietf, standards, sip, dan york, sip identity, identity

As I mentioned previously, the “RUCUS” BOF about voice spam at IETF 71 in Philadelphia is one of great interest to us. Unfortunately BOF co-chair Hannes Tschofenig ran into a problem with his domain and had to move the page to a new URL: http://www.shingou.info/bof-rucus.html

If you saved the URL or sent it on to someone, you’ll need to update to using the new URL. If you didn’t visit the RUCUS page before, please do check it out – and feel free to join the RUCUS mailing list. Of course, if you can, please do join us in person in Philadelphia!

Technorati Tags: spit, ietf, spam, rucus, standards, sip

Although I haven’t discussed it much here on this site, one of my passionate interests is in the whole space of “online identity” and what we need to do to have a better sense of “identity” online. There’s a number of levels to my interest but one very basic one is the ability to have a single “identity” that you can use while logging into different websites. Or perhaps not a single identity, but at least a small number of “identities” such as one online identity to login to “work” sites and another to login to “personal” sites. OpenID has emerged as a leading contender in this space and as I noted on our Behind the Blog blog , I have now enabled this site as an OpenID provider so that those of us who write here can use this site as an OpenID URL to login to sites. (And yes, I’m working on making the site a user of OpenID as well.)

In any event, while I will write more about OpenID in the future, over on his blog, Hannes Tschofenig writes about a new document “Technical Comparison: OpenID and SAML” that compares OpenID with the Security Assertion Markup Language (SAML). Here is the abstract:

“This document presents a technical comparison of the OpenID Authentication protocol and the Security Assertion Markup Language (SAML) Web Browser SSO Profile and the SAML framework itself. Topics addressed include design centers, terminology, specification set contents and scope, user identifier treatment, web single sign-on profiles, trust, security, identity provider discovery mechanisms, key agreement approaches, as well as message formats and protocol bindings. An executive summary targeting various audiences, and presented from the perspectives of end-users, implementors, tna deployers, is provided. We do not attempt to assign relative value between OpenID and SAML, e.g., which is ‘better’; rather, it attempts to present an objective technical comparison.”

It’s great to see this kind of technical research now coming out in the field. The more we have of this kind of work the closer we will be to having solid and secure forms of online identity. If you are interested in reading the paper, it can be found here.

Technorati Tags: identity, openid, authentication, security, research

Over on the Voice of VOIPSA blog today I posted about a new session has been approved for the IETF 71 meeting coming up in Philadelphia in March called “Reducing Unwanted Communications using SIP” a.k.a. “RUCUS”.Hannes Tschofenig, who submitted the proposal, has created a RUCUS web page and is looking for feedback. I’m planning to be at the RUCUS session at IETF 71 and would encourage others who want to talk about voice spam / SPIT to join in as well!

Technorati Tags: rucus, spit, spam, voice spam, voip, voip security, security, ietf, standards

As more systems get connected using VoIP and over time security systems come into use to help prevent voice spam, a.k.a. “SPam for Internet Telephony” or “SPIT”, what happens if you have an application that makes a very large number of outbound calls? For instance, a notification system? Might the traffic from that application not look like the beginning of a flood of SPIT?

Within the IETF there’s been a bit of discussion in the past months about voice spam/SPIT and just recently RFC 5039 from Jonathan Rosenberg and Cullen Jennings was published that specifically addresses the issue of SIP and Spam.

The RFC is an excellent summary of the current thinking about the SPIT problem and potential solutions to address it. If you haven’t read the document, I would *highly* recommend it.

A concern I had, though, was that it did not appear to me that existing documents address the issue of what SPIT could look like at a network level. For instance, if a network administrator monitoring network traffic suddenly saw a large flood of SIP INVITE packets coming into his/her network, it could be:

1. a telemarketer/spammer launching a flood of SIP connections to deliver SPIT;
2. an attacker launching a DoS attack through one of the various SIP attack tools out there; or
3. a legitimate notification system starting to notify a range of SIP endpoints.

I could very easily see existing network tools that look at traffic and perform anomaly detection (and potentially source suppression) being modified to suppress large flows of SIP traffic. This last case of legitimate traffic concerned me and so I put together an Internet- Draft talking about the types of legitimate systems that might generate a significant volume of traffic that could resemble SPIT (or a DoS attack).

I put the document out primarily to stimulate discussion. Are these legitimate scenarios being addressed in current thinking about SPIT? If not, my point really is that they need to be considered.

Comments about the document are very definitely welcome. Are there other scenarios I should include? Am I accurate? Am I overstating the case? or what?

Technorati Tags: ietf, security, sip, standards, voip, voip security

Over on the “Voice of VOIPSA” weblog, I posted about an excellent overview of SIP security issues that Hannes Tschofenig presented yesterday at the 3Rd ETSI Security Workshop in France. If you aren’t familiar with the current state of SIP security, I’d highly recommend you take a read through Hannes’ slides.

Technorati Tags: identity, ietf, security, sip, standards, voip, voip security