ADVENTURES OF AN ETERNAL OPTIMIST

I've just come across “Adventures of an Eternal Optimist“, a new (for me) blog by Pamela Dingle. She is a systems integrator in the field of Identity Management who works for a company called Nulli Secundus. Many in the identity community will know her from the excellent and sometimes artfully rhetorical questions she comes up with at the conferences.

She's reviewing the InfoCard bits and posting good stuff. She liked the Identity MetaSystem Design Rationale Paper:

There is a lot of info packed into these 11 pages – it is densely formatted, and there are no flowery sentiments. Terse is good. I like terse.

She also posted a balanced critique of the current version of the InfoCard bits…

As most of you know, I’m pretty excited about InfoCard. I’ve been playing with it for a while now, and I think I need to mention a few of the things I’ve noticed. I’m very aware that I’m working with a CTP – and I understand that there is a finite group of people that can only do a finite amount of work before Vista goes live. I hope I’m mentioning things you already know about and are planning for, Stuart! I don’t believe that these points can be considered nitpicking – they are pretty important, in my opinion.

I expect to be posting more of these entries as I get time, so stay tuned.

1. Export Prevention

As of the Jan 2006 CTP, there is no way to prevent a person with access to your account from exporting your InfoCards. If I walked into an office where the person had not logged off or locked their screen, I could have their entire card set saved to a file on the network or to a USB key in under 60 seconds, without ever being challenged. In fact, instead of being challenged for a password, the attacker is asked to set one! This password is needed in order for the infocards to be imported elsewhere, but it doesn’t protect the user from an attacker who sets it in the first place.

One more scenario to drive the importance of this issue home – there is nothing a parent can do to prevent their child from listening to the instructions of the nice man in the chat room, who tells them how to export infocards belonging to the whole family, and email them off (this of course assumes that the family shares an account – if the child has their own account, then the question of how to control what cards are placed in that account arises). If the cards are pin-locked, they are tougher to get into – however, the attacker can take as long as they want to try and crack the pin.

Keep in mind – I can only assert this regarding self-issued infocards. I don’t have a managed infocard to test with, but my understanding is that a lot of the built-in security that Infocard developers have spent a ton of time on kicks in when you start dealing with managed infocards. With a managed card the data is no longer part of the export, and a new trust relationship has to be established between the Identity Selector and the Identity Provider in order to view managed infocard attributes. This gives you the time to cancel your card, and it gives the Identity Provider the chance to notice that all of a sudden your infocard is being viewed/used from an unknown IP address. Still, if the Identity Provider is not sophisticated enough to notice, you might be up the creek — infocard exports are not even logged under Site Usage, so if somebody does export your cards and walk away, you won’t even know it.

2. Deletion Prevention

Along the same vein – a user cannot guard against accidental or malicious deletion of infocards. In the case of self-issued cards, it isn’t tough to re-create – after all, there are no more than 14 fields to type in. Deletion of managed infocards could be much more of a pain, depending on the process involved for re-provisioning. As well, upon deletion all of the usage records are lost, and Deletion events are also not logged as part of site usage.

Thoughts/Suggestions
From a sys-admin point of view, the obvious eventual goal would be to be able to set group policy around infocards. Until then, if a network login was forced at the time the export/deletion took place, it would at least prevent malicious attacks on unattended workstations. In the case of a shared family account, I have fewer ideas.

This all boils down to control. Visibility and control are keystones of Infocard – and as such, I think that the user or sysadmin has to (a) be able to see events such as exports in the log files, and (b) be able to place X credentials and ONLY X credentials on a managed desktop or account, and to prevent those credentials from being removed or copied. I do realize that you could call that second point a loss of control from the point-of-view of the user with the managed desktop — but the truth is, such relationships exist, and for good reason. The tool has to handle such demands.

So? Am I crazy? Is this not really such a big deal after all? Let me know what y’all think…

Certainly, in the home, people should be using different accounts for different family members. With “fast user switching” this actually works very well. I'm looking for stats on how much progress we've made in getting people to do this.

While it is true that people who get physical access to your machine can delete your infocards, they can also delete your whole filesystem. Presumably if you have such people around you should at least employ an automatic screensaver with password protection, and do backups from time to time.

The deletion problem is a “denial of service” and these are mostly impossible to prevent if people have physical access. For example, the opponent could take a very large hammer to the PC and you wouldn't be able to use your InfoCards no matter what we do.

Pam's critique of the way card export works strikes me as something we must address. I'll get back to you after discussing this with the team. At the RSA convention I promised Pam that if she found something that could help in our threat analysis I would buy her dinner for two and a visit to a spa. So I fear I'm in trouble here.