Slamming SAML..... NOT!

Jeff responds to my note earlier suggesting that using psudonymous identifiers adds security depth:

This is a very dangerous suggest as it implies that SAML is not secure enough without pseudonymous identifiers, the use of which makes SAML deployment a lot more complicated. Pseudonymous IDs are for privacy not security. If your system requires them to be secure, you have done something wrong. Period.

I was in no way suggesting that SAML was not secure enough. However, I am of the opinion that any SSO system (including SAML) is weaker, from a security and a privacy point of view, without pseudonyms than the same system would be if it was using pseudonyms. That doesn't say or imply that it isn't secure without them, just that it would be better with them.

And I stand by my statement that had Google used good pseudonyms across relying parties, the impact of their lack of the audience restriction would have been minimal. That isn't saying that I think a system should rely on pseudonyms as their primary security model, just that the effect would have severely reduced the impact of the error.

Tags : identity / SAML

Pseudonymity would help

Kim Cameron writes of Google's failing to scope SAML assertions:

But according to the research done by the paper’s authors, the Google engineers “simplified” the protocol, perhaps hoping to make it “more efficient”? So they dropped the whole ID and scope “thing” out of the assertion. All that was signed was the client’s identity.

The result was that the relying party had no idea if the assertion was minted for it or for some other relying party. It was one-for-all and all-for-one at Google.

While I agree totally that the intended recipient should have been identified within an <AudienceRestriction> in the SAML assertion (how SAML shows the intended scope of the assertion) the problem would have been moot if Google used good pseudonymous identifiers for its users.

Pseudonymous identifiers are random identifiers that change for each relying party (so my identity at relying party A might be 123 while my identity at relying party B might be 345). Good pseudonymous identifiers are large random values (so that they are unpredictable) and are not reused across multiple users (so the same identifier is never used at different relying parties for the same or different users).

The primary impetus behind pseudonymous identifiers is to prevent the use of the identifier as a correlation factor across multiple relying parties -- in contrast, a globally unique identifier would allow relying party A to ask relying party B about what user 123 did yesterday, whether or not the user was around. However, pseudonymous identifiers also provide the following benefits:

• added security depth - an unknown user identifier adds another layer of security on the SSO system (which, in this case, would have protected the user accounts from attack since even if the assertion went to a different relying party, there would be no user account with that specific identifier, so it wouldn't be useful).
• easier integration of new partners - when integrating new partners, the identity systems of the partners may have different data structures for user identity (at it's most simplest case a new relying party may store user identifiers in 32 bit integer values, while the IdP typically uses 128 bit random values -- a system that supports good pseudonymous identifiers and the assumption that identifiers are different on each system will easily be able to handle this.

One might be concerned about how relying party A could invoke a service of relying party B when they are all using different identifiers (such as a google relying party using Google Checkout). This is pretty simple. Typically, any such service invocation requires relying party A to get a security token for the user at relying party B. When that token is obtained, the issuer does the identity translation. SAML provides for the protection of the identifier in the assertion using encryption since relying party A should never know what the user's identifier is at relying party B and the assertion is given to relying party A.

Liberty ID-WSF provides several entities that provide this translation services depending upon the topography of the deployment. The most common such service is the ID-WSF Discovery Service.

Similarly, in WS-*, the WS-Federation Pseudonym service is called out to perform the same translation service (and it is possible for a deployment of a WS-Trust STS to perform this translation internally during token generation).

I strongly recommend that any deployment of SSO, even within a single enterprise, make use of pseudonymous identifiers. They only strengthen the identity infrastructure.

Tags : identity / Liberty / ID-WSF / ws-federation / google / SAML / pseudonymous identifier

Perhaps not so much Bashing...

Kim responds to my note about SAML Bashing:

...which is, by the way, absolutely NOT my intent. I’m simply trying to understand how SAML relates to linkability, as I am doing for all the other major identity technologies. I can’t take up all the points he raises, but encourage the reader to look at his piece…

Perhaps I reacted too negatively, but the analogy of some unknown clerk reaching into my pocket really irked me as that clearly isn't what happens and it appears to be written to instill unreasonable fear in an implementation of a browser-based SSO protocol.

I’m not criticizing or discussing the profile for an Enabled Client/Proxy. I was talking about SAML as we know it - in the mode which has been widely deployed in portals all over the world.

I think such analysis should be based upon the capabilities of the protocol and not about what some deployments have chosen to do within their environment (where they clearly felt that browser-based SSO meets their needs (and in many cases is mandated by the deployment scenario).

I think Conor is misunderstanding my intentions. I agree that with a completely trustworthy Identity Provider following best practices for end user privacy, Conor’s b) and c) above would apply. But we are looking at linkability precisely to judge the threats in the case that parties to identity transactions are NOT completely trustworthy (or are attacked in ways that undermine their trustworthiness.) So arguing that the identity provider will behave properly has nothing to do with what I am exploring: risk. I’ll try to build Conor’s concerns into my ongoing discussion.

I'm sure there's some misunderstanding here. I normally find that I agree with most of what Kim has to say and really respect his opinions.

As far as the trustworthiness is concerned, there's nothing that is completely trustworthy, not even if I make the decisions myself and hand-code the response messages from the keyboard (I'm sure that I will make mistakes of judgment and or typos).

I would ad that the same "attacked in ways that undermine their trustworthiness" applies to client implementations that try to enhance privacy protection. They too are subject to being attacked. Nothing is totally foolproof and I'm not sure which has more likelihood of successful attack, a service maintained under contractual agreements or open software systems in the hands of end user.

I certainly have chosen to put my money in a bank rather than store it under my mattress. Yes, the bank is more likely a target for a robbery, but they are legally obligated to maintain my funds, even if they are robbed. Similar decisions will be made by many people in the identity space (and yes, some out there will always keep their funds in their mattress).

Tags : identity / privacy / SAML / CardSpace / liberty

SAML Bashing

Kim writes about SAML's use of redirection protocols.. To start with, he forgets to mention a few important facts as part of his discussion:

• SAML defines a profile for an Enabled Client/Proxy (ECP) which is an evolution of the Liberty Alliance's LECP protocol. This protocol does *NOT* involve redirection, but instead supports an intelligent client directed by the user driving SSO transactions (a similar model to that adopted by Cardspace).
• The Browser-Profile that Kim is referring to is one written based upon a use case requirement that the profile work out-of-the-box on unmodified browsers. There is NO other possible solution that will work in this scenario that will protect the users credentials at the IdP.

That said, there are still several statements in Kim's analysis that I feel obligated to respond to. These include:

Note that all of this can occur without the user being aware that anything has happened or having to take any action. For example, the user might have a cookie that identifies her to her identity provider. Then if she is sent through steps 2) to 4), she will likely see nothing but a little flicker in her status bar as different addresses flash by. (This is why I often compare redirection to a world where, when you enter a store to buy something, the sales clerk reaches into your pocket, pulls out your wallet and debits your credit card without you knowing what is going on. (”Trust us.”)

First off, the user only see's nothing if a) they are already authenticated by the IdP, b) they have previously established a federation with the relying party, and c) they have told the IdP that they don't want to be notified when an SSO with this party takes place. I, for one, want things to work this way for me with providers that I trust (and yes, I do trust some providers). The inability to do this type of automatic operation is one of the shortcomings in Cardspace's implementation that I think will eventually be fixed. There is no need to have repeated confirmations of operations that I say may occur without my unnecessary participation.

Secondly, the analogy is way off base, trying to make this seem like I'm bing pick-pocketed by someone I don't know which Kim knows is absolutely not the case. A more proper analogy would be something along the lines of "I give one of my providers permission to reach into my bank account and withdraw money to pay my bill". I do this all the with providers I trust, such as my electric company, my telephone company (both wired and wireless) and may other companies.

So, returning to the axes for linkability that we set up in Evolving Technology for Better Privacy, we see that from an identity point of view, the identity provider “sees all” - without the requirement for any collusion. Knowing each other’s identity, the relying party and the identity provider can, in the absence of appropriate policy and suitable auditing, exchange any information they want, either through the redirection channel, or through a “back channel” that dispenses with the user and her browser altogether.

The IdP does not "see all". The IdP only sees that you have visited a particular relying party. It does not see what you do at the relying party. Knowing that I visited Amazon, is not the same thing as knowing what I looked at and/or purchased at Amazon.

Secondly, my choice of an IdP (as with most others) would be made based upon the appropriate policies and auditing capabilities at that IdP (just like I don't choose to use Johnny down the block as my bank, I choose a reputable firm and just as I would require the exact same policies and auditing in any client that I chose to use to act as my identity selector (yes, I have to *trust* Cardspace's or Credentica's implementation of policies just as I have to trust an IdP's).

In fact all versions of SAML include an “artifact” binding intended to facilitate this. The intention of this mechanism is that only a “handle” need be exchanged through the browser redirection channel, with the assumption that the IP and RP can then hook up and use the handle to “collaborate” about the user without her participation.

That isn't the intention at all. The intention, as Kim surely knows, is to pass a message by reference rather than by value. For the non-programmers in the audience, this means that I have a message that I need to send to the relying party (in this case that message contains an assertion, which can be big and complex and which has additional security requirements if passed through someone else's hands -- yes, the user can count as someone else). Instead off sending the token to the client to have the client then send it up to the relying party, I can send a small artifact that the relying party then presents to the IdP to get the token. The protocols explicitly define what the artifact is exchanged for -- it was never intended as, nor can it be used within the protocol definitions, as a general collaboration handle.

In many enterprise implementations, the artifact is used to allow the IdP to issue assertions to the Relying Party that don't need to be signed by the IdP. Clearly that isn't something I could do if the assertion was sent to the client (otherwise we'd be talking about how I took the token and edited it say I was Bill Gates when I sent it to his bank).

In considering the use cases for which SAML was designed, it is important to remember that redirection was not originally designed to put the “user at the center”, but rather was “intended for cases in which the SAML requester and responder need to communicate using an HTTP user agent… for example, if the communicating parties do not share a direct path of communication.” In other words, an IP/RP collaboration use case.

All SSO use cases (where one party authenticates a user and asserts an identity for that user at a relying party), redirection or not, would then be, by Kim's definition, an IdP/RP collaboration since the RP (Relying Party) is relying on the identity presented by the IdP. This has nothing to do with redirection or user involvement, or SAML in particular.

As Paul Masden reminded us in a recent comment, SAML 2.0 introduced a new element called RelayState that provides another means for synchronizing or exchanging information between the identity provider and the relying party; again, this demonstrates the great amount of trust a user must place in a SAML identity provider.

No. RelayState is designed for the RP to send information to itself, not the IdP, so that it can remember what the user was trying to access when the user is returned to the RP following a successful SSO operation. This is primarily used in the case where the RP is unable to set a cookie in the user's browser to remember that information. SAML even points out that as little as possible data should be included in the RelayState.

Paul's point in his comment was that if an RP used this incorrectly, they could leak information. The SAML specs contain exactly this caution.

I don't claim to say that SAML is the end-all for every use case. I do believe that we need to support multiple methods, some of which have different privacy implications. I also don't want some privacy weenies making life intolerable by the need for a confirmation of every thing that I already said it was OK to do. I do trust some of the parties that I interact with and want to be able to automate as much as I feel comfortable doing. I have no problem with the privacy weenie that wants to turn on the "let me approve everything" -- just don't force me to live that way as well.

Tags : identity / privacy / SAML / CardSpace / liberty

Keylogging & Security

In Identity X-File 0x01, Pam writes about a story in the UK where a 6 year old was able to bring in and install a hardware key logger on an MP's computer in the House of Commons (it was part of a BBC experiment).

I assume a physical keyboard logger like this could still be used to steal an IdP username & password, even with all the secure desktop stuff that the CardSpace client has built in…

Essentially what a key logger does is use a Man-In-The-Middle attack to capture all input to programs and applications (including login screens) on a computer. The captured data is then analyzed to pull out useful information such as login credentials, credit card numbers, and other such valuable information.

If the primary concern is login credentials, the "easy" answer is to move to some form of strong authentication that requires hardware assistance (such as a smart card or biometric reader). These usually have communications protections in them to protect against MITM attacks. This isn't so easy to implement across a number of vendors (especially if you try to do it without identity federation networks such as those discussed by the Liberty Alliance's ID-FF and OASIS's SAML 2.0) and, even if you were to do so, the non-credential data entered by the user would still be subject to loss (such as the content of all typed emails, documents, etc.).

I did stumble across one amusing way around loggers (but, IMHO, opens all kinds of other problems) which uses a screen based keyboard to enter your data by clicking on buttons -- theoretically this is less likely to be picked up by loggers. The problems with this model include:

• While you click on the keys, your credentials are displayed plain-text on the screen so anyone looking over your shoulder would get them.
• You are trusting that the party that manages that page is not going to add anything to that page to log your entries (and without looking at the code, there's no easy way to do so).
• The site is unencrypted, so anyone looking at your network traffic can get the data
• The way that you then copy the data to the appropriate application is via the Operating System's copy/paste routines, something that is frequently available to any application and so subject to attack.

I wouldn't recommend using such a solution. Just too many weaknesses for me.

The ultimate answer for key loggers is a Trusted Path (sometimes called "Secure Path"). The trusted path ensures that the user is talking to the application that they think they are talking to (i.e. that there's no MITM listening in). Microsoft talked about doing this in their Next Generation Secure Computing Base (NGSCB) (code-named Palladium), which, at one point was to be part of Vista. However, only a limited set of the NGSCB functionality made it into Vista - the BitLocker drive encryption component.

This problem isn't small and isn't easy to solve, especially when you consider the need for being able to replace keyboards (because they broke, because you want to try a more ergonomic version, etc.). If you make replacement easy, you make MITM easy. If you protect against MITM, you end up making it hard for your users to easily work with their systems (increasing IT maintenance cost).

Tags : key logger / Microsoft / Palladium / Vista / Trusted Path / Secure Path / MITM / NGSCB / SAML / Liberty / Liberty Alliance / ID-FF