Speaking of Standards

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