On RSS "security"
It's been interesting to follow the debate over the past few days about the concept of "RSS Security". Greg Reinacker made the point that saying "RSS security" alone is quite meaningless, and he breaks it out into encryption, authentication, and authorization. This is very helpful, since there is a huge tendency in the general public to think "security=encryption". i.e. "If something is encrypted, it's secure". Following that logic, in the HTTP world you have "if we use SSL it's secure" (tell that to someone whose bank account details were harvested over an SSL connection). In the early days of XML security, you had "if we use XML Encryption, then it's secure" - an even more meaningless case of throwing a specification at the problem.
Here are my two cents on this:
Security is the wrong word
The problem with saying "we provide secure RSS" is that it implies that RSS is inherently insecure. i.e. for "secure RSS" to be attractive in the marketplace, it has to contrast with "insecure RSS". It strikes me that what the market is really looking for is "private RSS" (which contrasts with "public RSS" for things like blogs, weather forecasts, and news). With "private RSS" you enable use cases like:
- A law firm can provide a feed of advisories to its fee-paying clients.
- An investment banking firm can provide investors and managers with a feed of information relating to progress on a floatation or an acquisition
- Sales staff in the field can be provided with a feed of the sales pipeline and notable sales events [You can already use Newsgator and others for this. And I understand Microsoft's CRM will do this too]
- An ERP system can provide executives with real-time information about goods shipments
Greg Reinacker's three requirements of Encryption, Authentication, and Authorization are all required to make those four "private RSS" use cases viable.
Client authentication isn't easy
Alexis Smirnov hits the nail on the head here. If a user is authenticating to multiple private RSS feeds using a password, there will be a tendency to use the same password for each (the real-world implementation of what is called "simplified sign-on"). Alexis mentions Project Liberty, which would allow authentication to one private feed to then be used for true SSO (i.e. Single Sign-On, not Simplified Sign-On) to other feeds, without the requirement to re-enter a password. Using SAML 2.0 and Liberty, you can take advantage of the new "Single Sign-Out" also (i.e. you sign out of one feed, and you are automatically signed out of all your feeds).
Aside from Liberty, there is also the very clever "safe single password" method described by Jon Udell here.
Another way to authenticate the clients, without storing passwords at the provider side, is PKI of course. But for the small logistical matter (cough cough) of distributing the keys to the clients, PKI would be the slam-dunk solution for enabling private RSS.
Group RSS feeds
I suspect there is a niche for RSS feeds for small groups who don't have the rock-hard access control requirements of an investment bank or a law firm, but would still like to create a private RSS field for "ourselves alone". The requirement would be to have a Yahoo Groups style method of creating the group, allowing users to self-register, choose their own password, be admitted into the group by an administrator, etc. This seems to me to tie in with what Justin Mason describes here.
But it's not just Encryption, Authentication, and Authorization
I mentioned above that I like the way that Greg Reinacker divides up "security" into encryption, authentication, and authorization. But, drawing on what Vordel has done in creating product to solve security requirements in the Web Services area, I'd go further:
Digital signing of RSS feeds has some compelling applications. Going back to the four use cases above, I could see a law firm automatically signing the advisories it provides to its fee-paying clients. This means that nobody could go back with an altered advisory and say "hey you told me to do this and it was wrong". The signature would make it tamper-evident. Does this mean you'd need XML Signature support on the client? Not necessarily, no. But you would need XML Signature support on the provider side [many of Vordel's customers already do this using our products].
RSS service health becomes a security issue, indicating the system may be under DoS attack. Even if the feed is responsive but not functioning normally, for example if it's spewing back error messages that include stack traces, that is a security problem. In Vordel's products, we've built support for detecting operational health problems in XML applications and then to understand the "ripple-back" effect on other applications which we're also monitoring and protecting (you can see some of this here: http://www.vordel.com/products/management.html#sla).
Tie-ins to existing corporate identity-management infrastructure. It's tempting to set up an "island" of access control rules for a private RSS feed, using either custom-written code or by configuring a Web server's HTTP-Auth rules. However, many larger organizations already have an identity infrastructure in place which should be used, rather than creating this new "island" of identities and rules. Back when we were talking with security architects about what they wanted in a Web Services security product, we continually heard the requirement that Vordel's security enforcement should tie into existing corporate identity and RBAC infrastructure. We built this support, so that Vordel products can slot into identity managment [e.g. Vordel's products are part of the Entrust Secure Identity Management Solution, and also connect into identity managment solutions from IBM Tivoli, RSA Security, Sun, and others].
Remember that RSS uses XML, and XML has security vulnerabilities. At the risk of turning this into a Vordel infomercial ("It already is", you shout :) ), suffice to say that Vordel's XML security engine blocks all the publicized (and some un-publicized) XML level attacks (e.g. these two described here).
RSS enclosures - considered harmful?
Don Park talked about this back in June- "the primary mechanism behind podcast, RSS enclosure, can be used to deliver worms and worse to the desktops. " It seems to me that this is similar to the situation with SOAP attachments (MIME, DIME, MTOM). What we do in Vordel's products with SOAP attachments is that we pass the attachments in memory to a virus-checker. The "in memory" piece in that last sentence is the important part, since writing it out to the file system would introduce I/O latency and the wear and tear of spinning media. I understand that some of our competitors write the files out to the file system before invoking the virus checker - tut tut.
10:27:54 PM 
|
