On the idea of Portable STS (P-STS)

Already Sunday evening. It was a weird weekend, partially spent under the influx of powerful pain killers (dentist played alpinist with my jawbone: and no, do not expect any aesthetical improvements). That’s probably the reason for which I recalled this very specific idiosyncrasy I have for the hype around the idea of P-STS, often presented as THE solution of the roaming problem for CardSpace. I’ve been known to react to those expressing those opinions with disproportionate outbursts, I think the last public one was at TechEd EMEA (Keith & Dominick were in the same room :-)), but that’s not really fair until I give a decent explanation of why the P-STS is not the silver bullet for roaming. Don’t get me wrong: P-STSes have the potential of playing an extremely important role in roaming scenarios, it’s simply that alone they are not enough (perhaps for easy cases they may not even required). In order to make our point, we’ll make a little thought experiment: we’ll assume that a P-STS device do exist, and we’ll try to use it with CardSpace V1 ie what’s available today.

First: what is a portable STS (or P-STS for brevity)? The market is not exactly ripe in that space, so there’s not really an official definition for it: we’ll have to settle with my intuitive idea of that. Here it goes:

A portable STS is a WS-Trust endpoint that is capable of issuing security tokens (ie: implements the Issue action), whose code resides & executes on some sort of pluggable device.

With “some sort of pluggable device” I mean some super smartcard, a USB dongle, you name it. The form factor is important in term of usability & uptake of such a device, but from the trust chain viewpoint it it doesn’t really matter. The little STS that lives on the device is able to issue a well known set of claims, and that it contains the values of those claims as well. Also, the factor required for securing RSTs is known: for example, it seems reasonable to use an X509 that lives on the device itself.

Let’s say that when you plug such a device in your system the corresponding endpoint becomes addressable by your system: something like http://mydevice/sts. It may not happen exactly like that, you may have special protocol schemas or a unique URI, perhaps the device may impose its own secure APIs instead of directly exposing the ws-trust endpoint, whatever: again, for the discussion here it does not matter. If I have an STS address and a list of claims, and assuming that there is a valid ws-mex endpoint as well, I can create a managed card that points to it. Cool! Are we roaming yet?

Ehm… nope. What we obtained is some sort of personal card on steroids! Check out the sketch below.

 

On the top-left corner there’s a pic of our imaginary device. Like every STS worth its name, it has its private key (triangle head, red). Then there’s a little store for claim values, which I’d expect to be reachable only via STS. Below that, there’s the STS itself: here it represents code that runs directly in the device chip, so that the hosting computer cannot fiddle with it in any way (think smartcard signatures). Finally, I’ve added an extra set of keys (round head) for representing an x509 and its private key, so that the device contains both the STS and the auth factor needed for authenticating RSTs (hopefully there will be a pin to be entered at some point to protect it from unauthorized use).

The device is depicted as inserted in a PC (blue rectangle). On the same PC there’s the managed card we described above: it points to the P-STS endpoint, and uses the x509 mentioned above as UserCredential.

Let’s assume that we have an RP which needs claims from the ones that our P-STS can produce, and that such an RP does not specify an issuer (we’ll elaborate on this later). I’ve spared you the usual RST-RSTR dance: what you see in the middle of the picture is the message that is sent to the RP once a suitable token has been obtained. You’ll notice that the token has been signed with the red triangle key. With a regular STS, that would mean that the miracle of federation is about to happen: the token would arrive from a well known authority, and the RP would know the corresponding public key; if the signature would match the call would succeed, even if this particular user would be calling this RP for the very first time.

But a P-STS is not a regular STS. I cannot say it for sure, as I’m not a smartcard expert, but it seems reasonable to imagine that every device would have a unique (triangle) key: as an authority I would not feel comfortable in delegating my signing power like that. If every device has its own special key, there’s no federation to speak of: every [corresponding public] key, or derivatives like the UniqueID, must be recorded explicitly in the RP authentication store. Exactly like in the selfissued case. Right, here I can have an arbitrary set of claims or issue exotic token types, whereas personal cards are constrained on both dimensions; and I can use a P-STS in offline scenarios and private networks, where connectivity to an authority would be a necessary condition in the traditional scenario. Furthermore, there are obvious advantages in having all those operations performed on truly trusted code. That said, even if every device would have the same signing key that would not really affect the following roaming considerations.

Let’s say that you extract the device, you pocket it and walk away. You get to the PC of a friend of yours, and you want to access the same RP from there: can you?

No, you can’t. Unless you export the corresponding managed card and you re-import it on the PC of your friend, your portable STS will keep sleeping in the cozy chip of your device. Wait a minute, isn’t this exactly what you have to do today for moving any card type?

Ahh, we’re finally where I wanted to get. Roaming requires to do something with the cards store. The P-STS can really help a lot, in fact it seems the only way of reproducing personal card behavior when using a device, but in the end what needs to roam are the cards themselves rather than the token issuers. In fact, if you’d want to roam only managed card you may not need a P-STS at all: card metadata and authentication factor would be all you need, if the issuing logic runs on the remote STS as usual. 

Now, working on the store is the real challenge. I won’t go into further details on that, I am not deep enough on the issue and I’d almost certainly say some silly thing: besides, people smarter than me are working on the problem and I’m sure they’ll come out with something just great! 🙂