January 25, 2007

Extending OpenID Authentication Scheme for Communication Systems

A few weeks back I had suggested that OpenID could be used by the end parties in an IP Communications session to authenticate the originator of the session. At that time I only a sketchy description of the procedure. The following is an elaboration on the procedure. I am open to hear your feedback.

Recently OpenID has caught on the attention of many as a simple and effective way to authenticate users visiting a website. It is "is an open, decentralized, free framework for user-centric digital identity." It is noteworthy that for the purposes of authentication it is only required that the visitor and the OpenID Provider (OP) have a prior business relationship and none are required between the site owner and the OP. The objective of this note is to explore ways in which the OpenID mechanism be reused for other applications like authenticating an email sender or the originator of a SIP session. Since the OP can be the visitor, such an authentication scheme will not eliminate SPAM and SPIT. But it will be easy to maintain an effective whitelist and if necessary institute a "postage" like regime for people not on the whitelist.
This proposal is a modified version of an earlier and related proposal, OpenIDHTTPAuth.

We will use the terminology used in OpenID specification. Accordingly, in our context, the User Agent (UA) is the party initiating the communication session, the Relaying Party (RP) is the the other party in the session.
The suggested procedure is a simplified and adapted version of OpenID 1.1's "dumb mode".

  • The UA will send to the OP a checkid_immediate message omitting the parameter, openid.assoc_handle. After performing the customary authentication procedure, OP will return a response message. If the assertion is positive the response message will contain among other things the parameter, openid.assoc_handle.

  • The UA will pass along the contents of the response message to RP using the native protocol.

  • If the RP is interested in authenticating the UA's OpenID, it can invoke OpenID authentication procedure. RP can fetch the identity URL given above and discover OP's URL. It then issues a standard OpenID 1.1 check_authentication request to the OP,

Example Applications
The sender of an email can attach the validation response it received from OP to the email as an attachment with a well known file name. The recipient then can use the content of the attachment to authenticate it with OP.
The initiator of a session can include the validation response it received from OP to the SIP INVITE message as a MIME encoded parameter. The recipient then can use the content of the parameter to authenticate it with OP. If the initiator did not include this parameter, but the recipient prefers to authenticate the initiator, the SIP protocol could be extended so that the recipient can request the authentication information by sending an INFO message.

If the UA did not include the necessary credentials, the RP can use the native protocol and ask the UA to initiate the authentication procedure.
As observed by OpenIDHTTPAuth, "This method of authentication is completely stateless and applies only for one request. The client must repeat the signature generation for each subsequent request, both because the request URL is part of the signature and because the identity provider can then use a different secret for each request to avoid replay attacks."

Security Considerations
Replay Attacks
It is important that OPs use techniques like nonce to reduce replay attacks.

Posted by aswath at 02:16 AM | Comments (0)

January 16, 2007

IT is a Collection of Tubes

The IT is not Senator Stevens' Internet, instead it is your data according to Adesso. Liz Gannes told us yesterday about a new product called “Tubes” from Adesso. Tubes allows a group of people to share data file among themselves with different write permissions. In a nutshell, one user establishes a Tube and adds other users to it. The user also associates one or more data files to the Tube (at the time the Tube is created or at any time thereafter. From that moment on all the members belonging to the Tube can access all the associated files. They describe how the product works in a short and informative clip. According to this AP story, each Tube is restricted to 2GB. I thought I understood the technology and the business model. But there is more to it and it is not clear to me what is their operating model.

For example, they claim that this works both offline and online. This means that they store the files locally. If that is the case, why there is a restriction on the file size? They have to store the files in their servers at least temporarily so that members of a Tube can pick them up. If we use Amazon's S3 as a benchmark, the storage cost is small compared to the bandwidth cost. So shouldn't they be placing a cap on that? Is it because, the general public has a better handle on consumed storage rather than consumed bandwidth?

Posted by aswath at 10:39 PM | Comments (1)

January 15, 2007

Illegality of VoIP - Exaggerated

Last month there was a news report that the Indian Government was “planning a clampdown on BPOs and KPOs over, what it feels is, illegal use of internet telephony.” Indeed, Om Malik and Tom Evslin noted in their respective blogs on this news item and the story was even slashdotted. At that time I tried to pint out that this might be a case of bad reporting; but I couldn’t produce supporting material. Even today I can not produce a satisfactory reference for my position; but I can point out a circumstantial one. Today I happened to come across another news item in India regarding a paper filed by VON Coalition with the Office of United States Trade Representative. As you know, VON Coalition is a trade association of companies that have financial interest in VoIP and one of the leading proponents of changing the regulatory environment that supports VoIP technology. In effect I am using a potentially a “hostile witness” to support my claim. Please keep in mind that VON Coalition submitted their letter about ten days after the Indian story broke out, still they failed to reference it.

VON Coalition submission states that India legalized VoIP in 2002 (they add only, but that is besides the point). It also points out that (as I have stated many times before) “VoIP can be used for making phone calls from a PC to a phone abroad, PC-to-PC within and outside India, and between two PCs globally.” There are restrictions only when interconnecting to PSTN in India. Effectively, the restriction states that one can interconnect to PSTN only at the International Gateways and there are regulations and fees for such interconnections. This is very much like the case of Iowa. As I have said before, if we truly believe that VoIP is going to take over, why bother about it. Last month news story made a big point about the planned clampdown will impact BPOs and KPOs. Here again VON Coalition gives the clarification. There are no restriction for BPOs and KPOs to use VoIP to conduct their business with overseas customers. The problem comes only if they connect to the PSTN, just so they can reach their employees (presumably at branch locations or home offices): “Similar restrictions also apply to private enterprises that wish to use VoIP to provide internal communications to their employees. For example, a ban still prohibits enterprises from using VoIP to directly call the Indian PSTN. Enterprises must partner with Indian telcos in order to permissively terminate VoIP calls to the Indian PSTN.” This restriction will not curtail their operations at all; but on the other hand if such a restriction is not in place then there will be many enterprises declaring themselves to be BPO or KPO and their employees are the general public and will be terminating calls to PSTN thereby undermine the original regulation.

Now you may take issue with regulations as such but the point to observe is that only PSTN is protected and regulated – a grandfathered situation. In India, the IP world is free of regulations. And today I say with much more confidence that the original story is badly reported and poorly edited. Do you want to take a wager whether this post will get slashdotted?

Posted by aswath at 04:59 PM | Comments (2)

January 11, 2007

Implications of Apple's iPhone

I am sure that you have heard of Apple's announcement of their new consumer device that they call iPhone. Indeed, you are sated with this news that you may wonder I am writing about it this late. Mark Evans has given my excuse. It seems that Apple started to work on this product around two and half years ago. Almost around the same time at the urging of Om Malik I wrote an open letter to Steve Jobs suggesting a radically different approach to telephonic devices. We could safely assume that no one at Apple, let alone Steve Jobs, read that letter. Actually, that was not my intention; it was just a convenient literary vehicle. Now that Apple has announced a device, it is worth reread that letter to see what Apple has achieved and we could expect from others.

Without any doubt, iPhone is much more than what I was talking about in that letter. It is an engineering marvel and many breakthrough technologies have been used. But more importantly, it has made vast improvements in the UI of the phone. In my opinion, the last major UI breakthrough was made some 25 years back by AT&T Information Systems (as Avaya was known then). AT&T's DCP phone introduced the concepts like call appearance and status indicator lights. These allowed the user to unambiguously control the calls. Now iPhone takes the UI to the next level. Even a quick look at the screenshots available at Apple's website will tell you that. In this respect, it delivers on the second request made in that letter – a rich UI that allows for straight forward invocation of features. Take the conference call scenario they demonstrate on their website. A call is received while on the first call; the user is able to place the call on hold, take the second call and the bridge the two calls. In a standard phone one can do only one of the two – go back and forth between the two calls or bridge them together. This is possible because of the rich user interface – they are able to display two buttons, one for “hold” and another for “merge calls”. This way one can eliminate many of the feature interactions and offer a less restrictive feature set.

But iPhone is a cell phone and not really a VoIP client. So it requires a service provider. But for some reason, one can presume for business reasons, they have decided to have an exclusive partnership with a single provider – Cingular. Tom Evslin has commented on it at length.

Apple and Cingular have commented on the tight partnership they have forged and how Cingular has gone out of their way to accommodate Apple's requirements. I will make a much stronger point: with device Cingular has agreed to loosen its grip on feature realization that the incumbents refused to do during ISDN days. In ISDN parlance, they have admitted a “functional terminal” (“intelligence at the end” for Netheads). Of course, an implication of this is that now features can be realized by the end devices. More importantly, the carriers can not introduce new features on their own accord; they need to coordinate with the device manufacturers – after all the UI may be impacted. In my opinion, this hits one of the objectives of IMS. IMS anticipates third party application developers. With iPhone around, third party developers now have to work with not just the carriers, but vendors like Apple. So in effect Apple could be in the critical path of new features.

In the short span of two days, Apple has managed to convince many that “Visual Voice Mail” is their creation. Indeed Apple claims that Cingular expedited their processes to accommodate this service. But I do not agree that Visual Voice Mail is a new service. After all, every “Voice mail as Email” is also a “Visual Voice Mail” service. I think Apple does not deserve the credit for this.

Given the cost of the device I don't think I will buy this in the near future. But, if I did, I can use it many interesting ways. For example, I will use PhoneGnome at home and give out only the home phone number. I will monitor call activity at PG via iPhone's browser, control the calls via a “Relevance Engine” running in the iPhone itself and forward the call to the cell phone if needed. But I am eagerly waiting for other device manufacturers to add screen based phones and improve user experience, not just for cell phones but for wireline PSTN and VoIP phones as well.

Posted by aswath at 11:45 PM | Comments (3)

January 01, 2007

Happy New Year!

This is to wish all of “You” a Happy New Year!

This is also a time to take a stock of this blog which is three years old today. I had not posted as regularly as one is expected from a blogger, and is reflected in the number of visitors declining over the course of the year.

My Blog Traffic

But Alec points out that my Text-Link-Ads Juice is 3.7; if you dig deep into that statistic the component numbers are reasonable. This suggests that you find my writings continue to be of interest. I hope that I maintain your interest in the coming year as well. Thank you.

Posted by aswath at 10:48 AM | Comments (2)

Copyright © 2003-2009 Moca Educational Products.